I was using a Discourse forum today and needed to find a specific piece of text on the page, so I did a Ctrl-F, which activates the built-in browser page search (at least in all the browsers I use regularly). For some reason Discourse blocks the use of Ctrl-F. Instead of getting the browser page search dialog, it presented me with what looked like a Discourse-specific search dialog. That in itself would not be too bad if it actually worked. So I went ahead and typed the characters I needed to find on the page, in this case "PR " (e.g. the letters PR followed by one space) and hit enter. Instead of highlighting the desired text on the page, the dialog simply vanished again with no results and no error message.
I tried it multiple times with the same result. I then tried searching for a few other random strings. I tried longer strings thinking maybe it just blocks searches of short strings for some reason but the same thing happens on longer strings, even strings that I could plainly see right there on the page - the dialog just vanishes when you enter the search. I finally gave up, did a Ctrl-A and copied the entire text out to a text editor and did my search there. I realized later there is a work-around in Chrome - if you use Chrome’s hamburger menu and select “Find” with the mouse pointer, you can search normally. Also if you do a Ctrl-Shift-I to get the inspect element function, then do the Ctrl-F, you can do your search as expected (with the exception that you may get hits on HTML or CSS elements in addition the page text of course). Still, a very frustrating bug, hope it can be fixed!
Also, sorry to post in the support forum here but I couldn’t find an actual bug report database anywhere for Discourse.
Not a bug, topics with > 20 replies do not have all content loaded in the DOM – we only load the visible posts, and unload the rest – so CTRL+F in that case would not find what you want to find. Please see many other topics on this here.
On short topics, all 20 posts fit in the DOM, so we don’t override search.
edit: ah, I see you are trying a two letter in-topic search. That’s a different issue, re-opening.
As @cpradio reminded me, you can press ctrl+f twice to override. Just bear in mind, not everything is loaded in the browser in a large topic, only the visible bits.
Hmm, @sam for in-topic search (because it is already so tightly scoped) should we relax the minimum search characters allowed to 2 instead of 3? I can confim that I can find “see” in this topic but not “to”.
Not for me. Just tried on this discourse. Typed Ctrl-F and as soon as I enter the search, the dialog vanishes with no results. (I tried “database” just like you did). I’m using Chrome on Fedora if that makes a difference.
edit: wait, I see another regression. This is a short topic (under 20 replies) so pressing ctrl+f should NOT trigger the in-topic search. cc @eviltrout can you have a look tomorrow.
Just tried the double entry method (Ctrl-F Ctrl-F) and that works for me. Easiest workaround so far, thanks! Might be worth putting a warning in the Discourse search dialog to that effect (“do Ctrl-F again to get where you expected to go”).
Ah, I think I just stumbled onto the answer. If I don’t enter the search but just leave it sitting in the dialog, after a few seconds the dialog box expands and shows the results. Never would have expected that. I’ve used Ctrl-F for years and you always have to enter the search before anything happens (e.g. [Ctrl-F] [search string] [Enter]). So it looks like the Discourse search has a fundamentally different UI than the browser search it replaces. I guess if that’s a bug, it’s just a violation of the UI principle of “least surprise”. I use Ctrl-F constantly on lots of sites and didn’t expect it to suddenly behave differently on Discourse. So my bad, apparently.
It might be good if for first time Discourse users, some kind of warning appeared when you override the Ctrl-F behavior to let them know what’s going on. Then you could drop it once the user has seen it a couple of times.
