Hacker News Reader

Comment by cronin101 | Hacker News Reader

I see lots of replies suggesting scrolling for a long time and then using CTRL+F.

However, this won't work if the page is using virtualised scrolling (common with React et al. SPA for performance reasons, to avoid huge DOM trees as the page expands). The majority of content that is outside of the visible window will simply be unmounted from the DOM.

I'm not sure what the best-practice for a webapp designer is here? Perhaps intercepting Ctrl+F and displaying a custom search that will do the correct filtering on the back-end and update/retarget the view? Azure DevOps does this but it's still frustrating if your focused element is not within the capture point for the event.

View on HN

> I'm not sure what the best-practice for a webapp designer is here? Perhaps intercepting Ctrl+F

Oh god no, the solution is simple stop reimplementing the browser in the browser.

Google Drive does this within Google Chrome, fwiw. I don't disagree with the spirit of your comment though.

I'd say Google and Algolia are the only companies with the resources and know-how in search that can even think of this. And probably even they shouldn't.

The result can give a much better UX if done properly. (If done poorly it's just frustrating of course...)

Just think of SPAs vs normal backend templated apps. The SPA can be much faster with poor network connection or when the data needed is large but unpredictable. Then the SPA can really shine, if routing is (re-)implemented well enough.

What about MX (machine experience)?

I would agree, if the opposite didn't make the page unusable. Infinite scrolling doesn't really work if you don't unload what's on the screen (at least it didn't the last time I tried it, in 2014).

That's a horrible UX.

A better practice would be to avoid infinite scroll and better yet to think carefully before using a full-blown SPA for a standard UI. If it's a web page as opposed to a web app, there are certain UX features that every browser supports out of the box and many, many users with keyboards will expect.

> Perhaps intercepting Ctrl+F

Please don't ever do that. I know one site that does this and I hate it.

Discourse [1], popular forum software, does this as well.

[1] https://www.discourse.org/

Not a fan either, but at least it allows you to repeat the keystroke to do a native page search.

This is infuriating. Every time I CTRL+F on Discourse I get upset.

At one point I had a user script that prevented certain key combinations from being intercepted. Worse than discourse is a hosting platform I was encountering frequently for a while, where pressing esc to stop the page from loading instead caused the website to switch pages to a login prompt for the site owner. Other offenders that annoy me include intercepting alt+d (focus address bar), Ctrl+n (new window, outlook captures this), Ctrl+t (new tab), Ctrl+a (select all), and other common keyboard functions.

Fix: Just add a dummy onkeyup function to the document root and body elements, and set @match rules for whatever sites annoy you. Occasionally you'll also need the more generic event handler function as well.

Google Docs does this, e.g. in a spreadsheet. I think it's reasonable in that context.

For what it's worth, if you really need to search e.g. "View" to figure out where the View menu is, the OS-native menu option still works.

For applications that's fine. I'm mostly refering to traditional websites/forums that should never do this.

It shouldn't be possible. That the browsers allow it is the real problem. Same with forced unmounting of resources from the DOM.

1. Open devtools. Disable cache. Reload the page. Go to sources panel. CTRL-SHIFT-F. Enjoy the JSON response.

2. Alternative: same but with web debugging proxy like Fiddler or Charles.

Yep. For JS-heavy pages with virtual scrolling (i.e. removing from DOM stuff that is out of viewport) there's no better solution.

that's what discourse does. it's frustrating because it's significantly slower than the built-in browser search, probably in part due to excessive network accesses, but also probably due to poor caching and inefficient implementation.

The custom UI is also IMO terrible. It's completely different than the browser Ctrl-F UI. It does not simply highlight and move to the matches. Instead it shows a "preview", so you have to navigate to each match separately and back to the search UI. And it just navigates to the matching comment, but for very long comments I still have no idea where in the comment the match is. Thankfully you can press Ctrl-F twice to get the browser UI.

I hate discourse's CTRL+F. When things like this happen I open the devtools and search in the dom, and it's a horrible experience too. I just don't want to learn each website's custom controls. Don't hijack my CTRL+F or my scrolling or anything else please!

The solution is to stop re-writing basic browser functions. Just let me scroll.

Google Docs implements custom search. Unless web frameworks start to expose some basic controls to the user, like pre-walled-garden Operating Systems, that's what we have to wait for

GitHub does this in workflow logs and it makes it impossible to copy/paste logs greater than the number of lines in your view.

Then you download the raw logs and every line has a timestamp so you need to write a shell command just to parse out the actual text you wanted to copy.

They also bind to the "/" to focus on their searchbox, which breaks the native behavior in FF (which would be a single-keystroke for Find in Page, at least meta-f still works). Google likes to do this too, e.g. Google Tag Manager.

> Perhaps intercepting Ctrl+F and displaying a custom search that will do the correct filtering on the back-end and update/retarget the view?

Stripe does this in their docs and I find it absolutely infuriating.

You can also use Ctrl+G

Reply on news.ycombinator.com