Technically, such a feature would be a wart, but it has been argued before that it is actually a miswart. The reason being that due to the infinite scroll mechanic, a large portion of the topic may not actually be available to the browser, so the browser’s built-in Ctrl+F cannot work correctly.
Oh, there’s no misunderstanding from me on that. I absolutely get the reasons as to why it’s a good idea. The thing is, to me (and others, I suspect), the
CTRL/CMD+F search paradigm is not about to change on the rest of the internet, so until Discourse proves the rest of the internet should change to follow their suit, then I’d prefer if the functionality was not forcefully hijacked. That’s really all. My personal preference would be to use an alternative shortcut like “/” (which now works, btw) and leave
CTRL/CMD+F alone. Keyboard shortcuts have always been a “power user” thing anyway, so I don’t see this benefiting the average user as it is.
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.
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.
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.
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.
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.
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.
… 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.
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.
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.