Is it ever acceptable for a web app to take over Ctrl+F for its own search?

The default answer is no, and your reason is one of the few that can override it — but the bar is higher than "our search is better".

What makes browser find-in-page valuable is that it is guaranteed. It works the same on every site, it never changes the page, it never sends anything anywhere, and users rely on that consistency without thinking about it. Every override erodes a guarantee that costs nothing to keep and is very expensive to rebuild once broken.

The condition under which overriding is defensible is roughly yours: the browser's behaviour is not merely worse, it is actively misleading. Find-in-page reporting no matches in a virtualised list is not a degraded result, it is a wrong one, and a user who trusts it draws a false conclusion about their data.

That is a real justification. It is also worth exhausting the alternatives before using it.

If you do it, the implementation details are what separate acceptable from hostile.

• Only when it can help. Intercept on the screens with virtualised or server-side content. On an ordinary page, leave it alone.
• Make the escape obvious. Pressing the shortcut again, or pressing escape, should get out of the way and let the native behaviour through. Some apps show a small hint: "Press again for browser search".
• Behave like find-in-page. Highlight matches, support next and previous, do not navigate away, do not lose the user's place. If your search does something dramatically different — running a query, changing the route — you have not replaced the shortcut, you have hijacked it.
• Never swallow it silently. The failure mode people hate is pressing the key and having nothing visible happen.

Get those right and most users never notice a difference, which is the goal.

Two things to check that are easy to miss.

Some assistive technology uses find-in-page as a navigation mechanism. Overriding it can remove a route through your content that somebody depends on, and they will not report it as a bug — they will just stop using your app.

Do not intercept while focus is in a text field. People use the key combination inside inputs for other things depending on their platform and configuration, and an app-level handler that fires regardless of focus is a constant low-level annoyance.

And offer a setting to disable the override. It costs almost nothing and it converts your riskiest decision into a preference.

Worth considering the alternative that avoids the whole question: make your own search discoverable enough that people reach for it first.

A visible search field at the top of the content, with the shortcut displayed in it as a hint, gets most users onto the right tool without any interception. Applications that do this well find that the Ctrl+F problem mostly evaporates, because people stop reaching for the browser's search when the app's own is obviously present and obviously scoped to the data.

Interception is then a fallback for the users who still reach for it out of habit, rather than your primary mechanism.