When building a rich web app, can it be acceptable to take over the CTRL + F shortcut to focus your app's search box, instead of the browser's searchbox? For example, an app's own search box can do a server side search, finding content that is not rendered on the screen.
If yes, when? If no, what are the downsides?
My use case is a frequently used business app with infinite scrollable content.
CTRL+F has an important feature by default in that it does not change page content: No elements of the page appear, disappear, or change content when typing and submitting find queries.
Focusing a general-purpose search field that does a search request is not helpful since it will break that expectation, by causing network requests and the contents of the page to change.
For "search in website", use any other key combination available, for example GitHub uses "S".
In my opinion, the only reason to overwrite built-in browser behaviour is if your website's implementation broke it in the first place, for example by using opaque rendering methods like Canvas (example: Google Docs) or virtualized scrolling (example: GitHub file view), where if no replacement was provided, the functionality would simply not work in any meaningful manner.
I would always tell people in my team (and remind myself) to be very very careful overriding any default browser behavior and only go for it if you are certain its an improvement. Through testing and verifying with development.
Reasoning is:
We actually did something similar in our platforms where we use "/" as shortcut to call the searchbox while keeping CTRL+F in place. So far it works for us and we are not noticing any breaking issues.
My advice would be: don't replace CTRL+F but find an implementation that complements the default behavior whilst keeping standards intact. Avoid the rabbit hole
Update
As mentioned in the comments, [ / ] is used more often as an alternative to triggering search. Firefox uses it for quicksearch, but more websites like Github, Jira and Figma use it to trigger their search.
/ is the "Quick find" shortcut in Firefox. Unfortunately GitHub also breaks that shortcut, so you're not the only one.
When you use shortcut keys, you need to make sure they don't interfere with screenreader shortcut combinations.
Also, as it's been pointed out several times already, Ctrl+F is already in use.
But if you do it anyway, you need to make sure that the change is communicated to all users, including information on how to activate the original Ctrl+F function.
WCAG 2.1.4: Character Key Shortcuts
WCAG 3.3.2: Labels or instructions
Depends on your definition of "acceptable", but if it means "done by a major web app vendor"; you should note that Google Sheets (Googles web spreadsheet app, which is extremely widely used) indeed hijacks Ctrl+F to launch in-app search widget instead of site search.
In general I agree with other answers here that CTRL+F should not be redefined. However, you mentioned that this is specifically for infinite scrolling content. In that specific case, redefining CTRL+F may actually help fulfill the user's expectation better.
I have on occasion visited a site with dynamic-loading, infinite scrolling content, scrolled down to load some additional content, and then come back to that site later. If I remember a word or phrase that I wanted to find again, my first instinct would be to hit CTRL+F and type in that word. BUT if the section I remembered is further down the "page" and hasn't yet been retrieved, the search finds no hits, and I'm left wondering if my memory is faulty. So a hijacked CTRL+F that also searches the server for unrendered parts of the page may help in that case.
That said, plenty of people, myself included, consider infinite scrolling to be a terrible design pattern. The fact that hijacking native browser functions may improve the experience is really a good example of why it's such bad behavior in the first place.
While I agree with GWv's answer, you may want to consider this alternative. I recall using a site that hijacked the CTRL+F feature by showing their own search dialog, but at the same time had a message in thier dialog saying to press CTRL+F again to access the regular browser Find feature. So by pressing CTRL+F twice you could get to the browser Find.
I could be wrong, but I believe it was the Stripe Documentation that did this. However, if you go to the documentation today, you'll see that they use the / to access their search. I have seen more and more websites (including YouTube) use the / key to put focus onto the application's search feature.
Edit: I was looking at the wrong Stripe documentation, the API documentation still has the behaviour I described above. But furthermore, they even have a checkbox to disable thier find dialog from opening on CTRL+F in the future.
/ is the "Quick find" shortcut in Firefox. If more and more websites are overriding that, I have to assume they aren't testing on Firefox, or aren't familiar with Firefox's shortcuts.
No.
People are used to their existing search that works across all websites.
Stripe API documentation overrides CTRL+F behavior and I hate it
What does CTRL+F (usually) do? Thus what do user expect it to do?
It searches for the entered string on the currently open page, jumping to the first occurrence and perhaps even showing all occurrences on the current page.
By hijacking CTRL+F you basically say "we know better what the user wants to do", e.g. "they actually want to focus our app's search box and search there for content that is not rendered on the screen" - and you violate user expectations that way. For the user that thinks "Ah, I just read that interesting article about XYZ somewhere on this page, where was it?" this is NOT what the expected, nor what they wanted. Also in a situation where connectivity has been broken a "native" CTRL+F continues to work (albeit on the cached content only) - your "jump to searchbox" solution doesn't.
I.e. this is a good way to turn off users.
So, if you aim is to impede usability, and discourage users from using your app, this is the way to go (perhaps even consider hijacking left & right click) - otherwise DON'T do it.
There is a strong consensus in other answers that for web sites ctrl+f should not be hijacked.
However there is some leeway for content editing applications as webapps (not applicable for normal content presented as "single page application) - for example, it could be appropriate for an app like Excel or Google Sheets; or for a rich web-interface like VSCodium, or for any other case where the web application effectively takes over the role of what would otherwise be a full specialized desktop application, and the browser is just a delivery mechanism.
So the big question is whether your 'rich web app' is closer to a rich webpage of content, no matter if it has some editing (for example, like stackexchange), in which case taking over ctrl-f would be inappropriate, or it's more like MS Office 365, in which case it could be.
I agree with the other answers here but wanted to add a small addition. In certain web apps like Azure DevOps the default ctrl+f is used everywhere but if you use ctrl+f while focused in a code view it uses a code specific find. So it may be applicable when you are altering the ctrl+f within a specific scope.
I am merely a dev and user and this is merely a personal opinion. I have no experience as a designer whatsoever.
There are times when I am on a website which uses some form of lazy loading, combined with the fact it's slowly "unloading" content which I scrolled out of view such as Microsoft Teams or Discord; mostly instant messaging services which I use through a browser.
Sometimes, as I scroll to a specific part of a conversation history, I attempt to hit Ctrl + F because I want to search for a specific bit of text in that specific part of the conversation. Seeing that the page removed content what was scrolled out of view, that makes perfect sense to me.
But alas, some of these websites got implemented in a way that whenever I attempt to hit Ctrl + F, it would catch it and the input focus would land into their own search feature which would search the entirety of the conversation and not just the specific loaded part which I am currently looking at. And I must admit it does make me give up on using Ctrl + F altogether.
Ctrl + K is also a commonly used alternative to Ctrl + F. Examples:
