Yeah, you’re right, I too would prefer Ctrl+F to work as usual. In hindsight I guess I came across a bit strong, but I had been leafing through the jargon file (it’s history for nerds; awesome history) and couldn’t help but shove that wart comment in there. 
1 Like
+1000 
1 Like
couldn’t agree more. I’m not sure why, but I don’t find the ctrl+f hijacking in google docs a problem, but it really irks me in discourse. I guess this is because gdocs mimics and extends the browser search with highlighting, [x] of [y] results and up/down arrows. If discourse was able to do this I think it would be less annoying.
1 Like
Personally I want to only enable the hijacking on the topic page, and not on topic lists like we have now, @codinghorror I really think this should be reconsidered, cause I actually use “traditional” search on the other pages and we perform no unloading so there is not technical issue with enabling it.
That said … about the topic page …
I 100% support hijacking of CTRL-F on topic pages. What would we call this user preference?
“Enable extremely buggy browser search on topic page”
CTRL-F on topic pages is a trainwreck, open a composer hit CTRL-F its just totally messed up. As soon as you scroll to the spot it has highlighted it replaceState kicks in and clears the search results. Besides DOM unloading in larger topics which makes it simply look broken.
So, instead. I 100% support PRs to improve our in-topic search, perhaps one’s that mimic more of built-in one (like scrolling to highlighted spot and dealing with multiple matches in one post and so on.
I also very much think we should stop hijacking in all other spots.
2 Likes
That’s a really really good point. I think this may be exactly why the Discourse implementation bothers me too.
This is very reasonable. I hope others will be able to help with this, because my ruby skills are next to non-existent (and I haven’t had much time to learn, or I would be doing so).
Probably fine, but I don’t think people are complaining about the topic list here.
I use Ctrl+F extensively to navigate topic lists on our (vBulletin) forum, and anticipate I will want to do the same after we move to Discourse, so I’m very much with @sam on this.
If the hijacking is to remain within a topic - and I fully understand the arguments in favour of that - could the shortcut menu please be annotated to indicate this?
I first discovered the hijacking yesterday when I pressed Ctrl+F, started to type and then realised I had somehow opened the Discourse search box by mistake. So I closed it and tried again, with (of course) the same result. Long years of experience with poor co-ordination has taught me that when unexpected things happen, it’s because I’ve hit the wrong keys by mistake, so I made a third attempt, carefully ensuring I got the intended keys, and only the intended keys. Still the search box opened. So I double-checked that I hadn’t accidentally activated Caps Lock, or any of the other things I’ve been known to do, but no. I checked the keyboard shortcut menu to see if something had changed, but it still showed the search shortcut as “/”. At this stage, I then chose to open Discourse search, and discovered this and the related thread.
A brief note in the shortcut menu would have alerted me to this from the start and saved both time and frustration on my part.
1 Like
Press CTRL+F twice to get the browser native search. Warning: results can be bad on topic pages because stuff is unloaded from the browser DOM as you scroll.
2 Likes
Now that’s a neat trick
I just amended it so we only hijack CTRL-F on topic pages, so this should no longer be a major issue.
2 Likes
I am sure plenty of jimmies will be rustled by having it on the topic page alone.
1 Like
… just when I got used to Ctrl+F actually finding topics on the other pages.
Then again, that’s just me, so don’t worry about it.
The actual shortcut “/” still behaves in that manner, so you can still use it.
If that’s a reply to my post, you’re missing the point. I was simply asking that the shortcut menu be amended to indicate that Ctrl+F will open the Discourse search from within a topic, to save the confusion folk like myself experience when things don’t work as expected.
2 Likes
We changed it so that ctrl+f triggers Discourse search only when there are more than 20 posts loaded in the current topic stream.
So on smaller topics, this now works like the browser default.
Only on larger topics will you get Discourse search, which is necessary because not all posts are loaded in the DOM (think 100+ replies) at any given time, only the visible ones are.
3 Likes
I find this to be a fairly acceptable compromise, given the technical limitations.
Is there a tutorial feature for Discourse? If there is, or if there are plans for one, maybe notifying the user that if a thread is too large/etc for browser search that it will default to built-in search?
We have heard pretty much zero complaints since we implemented the new “very restricted” we have no choice so we hijack system. Closing.
I did want to expand this now that I have seen some complaints about the restricted implementation.
We hijack when we have no choice.
While reading this post:
-
Hit CTRL-F / CTRL-F - type “universally” … nothing. (except for this post)
-
OK search in topic, post #1 and post #3 have this word.
When you are 40 posts into a topic post #1 and #3 are peeled off the DOM for performance reasons so it would be extremely surprising for it not to be found.
I can think of ways around this issue for say 100 post topics, we could unconditionally keep the text around and only strip off images with a “mini cloak” but then what about 5000 post topics? At some point we just don’t want to force the server to send tons of data you will not be reading down to the browser.
3 Likes
Just press CTRL+F twice if you think you’re smarter than Discourse. Find out if you are 
1 Like