Remove overriding of cmd/ctrl-f

ux
27

Because you triggered Ctrl + Alt + F (or /, same effect.), and that has no default browser binding to fall back to. Try on a larger topic like this one, and use normal Ctrl + F.

2 Likes
28

Thanks. That seems to be the reason. Anyone know why it is ctrl-alt-f on Chromebooks? Is that the standard keypress there or it is somehow not possible to override on that platform?

I wonder why not be consistent for Discourse across all platforms where possible.

29

It also yoinks the alt one normally, I’m on windows for example. There’s probably something somewhere here about compatibility or something.

30

Those users also expect control-f to search in the current URL, which the browser can’t do since only 20 posts are loaded. And the pop-up explains that if you want to use the browser function you just need to type control-f again.

This image shows a dark search bar or input field with the text "Click + f again to use native browser search" displayed in light gray color on a black background. (Captioned by AI)

Do you have a more intuitive way to allow people to search all the posts in the current topic?

1 Like
31

The astounding irony of this.

  1. Saw email update about this post.
  2. clicked link and started reading. See this statement:
    It would seem like what you would expect is for control-F to find the post you want in that topic, but that’s not what you want. What’s the “find the post in this topic even if my browser can’t find it” key? Isn’t having control-f not find a post in the current topic a violation of expectations?
  3. Wanting to respond, but realizing I wasn’t logged in, I highlighted and copied the text (so I could search/find it after logging in)
  4. Clicked login in top right of screen and did the whole login thing
  5. was redirected back to the post, but at the top of the thread.
  6. pressed cmd-f
  7. pressed cmd-v
  8. pressed enter
  9. finds nothing

Like, you can’t make this up. The whole point of this thing is to find things that “aren’t on the page yet” and it doesn’t work?

And to respond to the actual comment:
No, it’s not a violation of expectations. The expectations of cmd-f are that if it’s not on the page, nothing is found. cmd-f is not “search this ‘post’” on the rest of the internet. You’ve created that out of thin air. If the thing isn’t on the page, find nothing. That’s okay.

Aside #1:
Even when it does find something I can’t navigate the results without learning an entirely new paradigm (no, up/down/enter isn’t that hard - but it’s different and unique to discourse sites). I also cannot press cmd-f multiple times to iterate through found-results just like I can on the rest of the internet.

Aside #2:
The cmd-f functionality that you’ve built has various limitations that the native functionality doesn’t have, 'Your search term is too short." being one of them. I tried searching this post for / because it’s relevant and I’m unable to do so.

Aside #3:
It seems like a huge stretch that the reason for all of this is because some posts are really really really big and cannot be loaded on the page. I just find that hard to process in today’s internet with all the options we have for caching at every layer of the stack. Maybe thats the ‘bug’ worth solving for?

1 Like
32

I’m not sure I’m 100% following this? What’s the issue with pressing it twice? Doesn’t that do what you want it to?

1 Like
33

While I’m pressing cmd-f twice should I start triple clicking links too? Shall we implement that?

It’s kinda profound how badly you’ve missed the point here. You’ve changed the default of how a browser works. This is wildly unexpected.

2 Likes
34

I agree. My expectations are to find in the page. The hijack also breaks ctrl-g ctrl-shift-g behaviour.

It is understandable why Discourse might want to override this due to it breaking the user expectation that all posts for a thread are loaded. However, this might be solved by indicating exactly which posts are loaded or not. The old paginated approach is transparent in this regard.

Having a thread search tool is of course useful, whether in paginated or infinite scroll mode. It is just jarring/confusing to hijack one kind of search with a different kind of search instead of exposing it in a different way e.g. through ‘thread search’ button or a hotkey that doesn’t collide with standard behaviour.

I don’t want to complain too much, as the design decisions are understandable and I have learned to live with it, but I just wanted to point out that I don’t think the ‘violation of expectation’ assumption is correct.

35

There’s a combination of unexpected things that have to be balanced for the person searching… it’s a pick your poison situation.

  • Not all content is available when scrolling for performance reasons. Discourse supports various content like GIFs, videos, polls, calendars, iframes, charts, etc… there could be 1000 of these in a topic. Keeping all of this in the DOM can make a page unusable.

  • Users do not know which content is currently loaded, affecting the effectiveness of ctrl + f. This expectation assumes all content is on the same “page” and thus searchable.

Since the expectation is that ctrl + f searches the whole page, and the whole page isn’t available… there’s an attempted middle-ground.

You’ve already made a couple arguments to attempt to solve this:

  • Disable dynamic content (including images) in posts.

    This isn’t going to happen — we’d lose every customer we have overnight for any one of the competitors that allows dynamic content (Facebook, Discord, NodeBB, Khoros, Higher Logic, there’s no shortage).

  • Disable infinite scrolling and use traditional pagination

    More possible, but does it really solve this issue? You reduce browser load by only allowing a certain amount of posts to load per page, and users have to manually flip through pages to continue reading.

    Now ctrl + f works as expected here, but really only as well as your memory.

    If you just read 100 posts over 10 pages and want to find something you just read… is it on page 2? page 3? my memory certainly does not work that well.

    So now you end up probably doing something like… ctrl + f… back ctrl + f… back ctrl + f…?

To me it seems there isn’t one single great experience here, even if you’re sticking to browser defaults. With Discourse if you’re upset by the lack of the browser default, you have to learn one thing.

7 Likes
36

Just a friendly note that all posts and discussions should try and remain civil and productive. If things become too argumentative/reductive then I’m going to close this topic. :pray:

6 Likes
37

Nobody’s denying this. Just don’t hijack cmd-f to do it. There’s an uncountable number of other keyboard combinations to choose from. Pick any one of those.

2 Likes
38

right but the point is that ctrl + f doesn’t work as expected due to automatic paging, so the alternative is suggested first because it will actually search all the content within a topic

so I suppose given all the tradeoffs it’s a choice between explaining:

  • your search didn’t work because while you were scrolling we automatically turned the page, so you should click :mag: instead (or use / which is an alternative shortcut)

  • you might have a better time with our search, but if not use the shortcut again

Would you be equally annoyed if we didn’t capture ctrl + f and it didn’t work because we loaded some content away while you scrolled? would you then attempt an in-app search as a solution? try scrolling up and then trying again? something else?

Beyond “don’t do it because it’s the default” (which is valid, because expectations) there might be some additional arguments against it to consider as well:

6 Likes
39
  • the overriding is not unique to Discourse. Among other places mentioned, Microsoft office tools also override ctrl+F. And it’s done for similar reasons (ie. not all the text is available to ctrl+F)
  • the actual function/intention is not being overwritten. It is a “find a substring” function. If ctrl+F was overridden to be the bookmark command, I’d be sympathetic.
  • the naive browser ctrl+F function will often fail with no indication of why. It would be easy to infer the text is not present in the topic when it is not found, which is not guaranteed to be true. In a topic that isn’t trivially short, most searches will be false negatives. You place an expectation on the user to have an understanding of the infinite scroll implementation details in Discourse in order to use ctrl+F effectively
  • for the people that don’t like the overriding, and understand how the pagination of posts works, you just have to press it one more time

If the main problem here is we don’t want to break the user’s expectations, then ultimately I would say it’s a bigger evil to break their expectations in a cryptic way (ie. ctrl+F says “no match” when the text actually does appear in the topic) then to break their expectation transparently (opening the non-native search bar)

Keep it the way it currently is.

6 Likes
40

I understand the desire to keep the culture here civil. I support that but please consider moderating users instead. Closing a topic affects the entire community. This is a topic we clearly want to discuss.

41

I understand your point. The search function should serve two purposes: search for topics or threads and search for keywords within a topic or thread.

I am using “topic” and “thread” interchangeably, but I hope the meaning is clear.