I’m not sure why anyone thought it was a good idea to hijack the universally accepted “Find” functionality of the browser to open the search box… it’s nothing but frustrating when you’re trying to find text on the page. I noticed whoever implemented also decided they would be clever by also hijacking the less common “/” (vi-style) key shortcut for this as well.
Please at least offer a user-configurable option to disable and an admin-configurable default setting.
see also:
Ah, thanks. Just read it, and although it has been tweaked (as I’m seeing), the behavior is still inconsistent enough that it’s still very annoying. It’s one thing to conditionally do something on say, a mouse click, but another when you’re overriding a universally used-and-accepted browser shortcut for a browser built-in feature.
I’m not sure if I should reply to that thread as well, though, since I’m asking for the option to disable it.
@brpc, in being answered, your request would loop back onto the content (and even subtext) of the other thread. I’ll explain, but first:
An interesting note. CTRL+F isn’t captured when you have insertion point inside a form element (input, textarea, etc). So, you do get browser native text search on the page by pressing CTRL+F twice.
However! An option to disable CTRL+F capture then requires that browser native CTRL+F functions properly, which comes back to the fact that Discourse can’t provide that in topics of more than ~10 posts because it doesn’t leave the entire topic thread in DOM at all times. Bottom line then goes all the way to a root ideology of Ember.js, which is that an Ember application is not a traditional (flat) web page in the sense that caused the browser native CTRL+F to be engineered. That then makes it fully OK to capture and replace the feature with something of like-kind, because the replacement both works as expected (it does full-text search of the topic content) and solves an issue with what it is replacing (you can’t have accomplished the expected thing without the new thing).
I think it’s easier for everyone, now that the captured search feature is improved since the other topic began, to leave that in place. It works well: far better than explaining to laymen users why browser CTRL+F isn’t working, every time they encounter that and ask.
The one thing I really lament about it is the fact that the UI response is moved and looks different… but that’s a UX issue that I don’t expect Discourse to solve today.
Browser CTRL+F simply will not work since most of the post and topic stream is not in the browser DOM. So what you are proposing is for users to have broken functionality.
That is absolutely not what I’m proposing. I am not asking you to change, in any way, the search function of discourse. That would be ludicrous. Should my proposition be considered (which seems unlikely given the responses here, which is unfortunate), the search would still work perfectly fine via clicking the magnifying glass, which, if I understand correctly, is all that capturing CTRL+F is triggering to open.
That said, it’s confusing to me why this can’t be made an option, at least at the user level (i.e. enable/disable keyboard shortcuts). I personally find keyboard shortcuts on websites annoying, especially when using “Search for text when I start typing” on Firefox. I disagree with the notion that “search would be broken” if the keyboard shortcut was disabled.
CTRL+F in a topic has huge problems.
(1) is a killer problem, unless Suppress updating of URL during topic navigation is deemed a core option I am strongly against allowing users to experience a largely broken search experience.
Why not just an option to disable keyboard shortcuts with a warning, then? At this point I’m even fine with shortcuts being enabled by default (given the aforementioned issues).
Or, hell, if we’re gonna go full hog on the keyboard shortcuts, why not implement full VI-style shortcuts?
We cant really do that, its not fair to give this option to a user:
: enable built-in browser search unconditionally ( when enabled browser search will not function correctly )
Also, not against adding a VIM like mode as a power user thing
I’d like to see this if we can’t have the broken browser search functionality 
Should I create an issue on github for it?
Discourse doesn’t keep the page text in the DOM?! I have just three words to say about that:
Well, for a 1000 post topic how are you going to ensure all the text is in the DOM. It means ember cloaking needs to be amended to allow for a lightweight cloak otherwise ember views bloat, a rather big bite of work.
Also replaceState thing is a bug/missing feature on chrome that should be tracked there.
It doesn’t really matter if the native browser search is “hijacked” or not. Here is the problem:
Input: User presses Ctrl-F, types letters, presses Enter/Return.
Expected Result: View jumps to highlighted text, if there is a match.
Observed Result: User is taken to a completely different webpage.
The “expected result” is seen in Notepad, Chrome, even Google Drive which also commandeers Ctrl-F (as @codinghorror pointed out elsewhere). Cannot Ctrl-F be captured without violating the user’s basic mental model?
So the problem is you are pressing enter? In what context does one do an in page search (the checkbox must be ticked) and press enter?
On the topic page that is easily solved by having CTRLf automatically select “search within topic”
For list hijacking, it is not really fixable. @codinghorror I am not really convinced we should be hijacking ctrl-f on the topic list pages.
Hi Jeff,
I may not be making myself clear. The “context” I’m thinking of is almost every other desktop application I use. I can only speak for myself, but repeatedly using common software has trained me to expect UIs to work a certain way (the “user model”).
True, only in some software (e.g., MS Office, Eclipse, Adobe Reader X) is it necessary to press Enter to highlight the first result. In other software (Chrome, Firefox, Google Drive) pressing Enter is not necessary to highlight the first result; but it does jump to the next result. This isn’t at issue, but as you’ve quoted Bill Higgins against “violating users’ unwritten expectations of how a web application should look and behave” I can guess at what you might prefer.
The details of pressing Enter only confuse the point. All I was trying to say is that the unfamiliar Ctrl-F behaviour was a frustration after 10 minutes of browsing the Discourse demo, especially when it had unintended consequences like navigating to a completely different page.
Automatically search within topic should be default checked when keyboard search (vs. click or tap) is invoked from a topic page. At least the UI makes this clear now with the checkbox visible.
I don’t object to that at all, but in the lists, I am not sure hijacking CTRL-F is right, in fact I find that I sometimes want to use it for navigation so its impacting me.
Regardless, within a topic if you invoke ctrl f, the checkbox should be checked.