Re: [w3ctag/design-reviews] Find-in-page API(s) (#236)

You are correct, of course, all these things block, or rather reduce throughput capability of the platform (e.g., if lots of code runs in the pointer move handler, you can't process as many moves and the input becomes "janky".)

This is not just an inconvenience--we created a whole new feature (passive event listeners) to try and address this problem for scrolling performance. Now, perhaps Find-on-page is not in the same performance-sensitive class as scrolling, but "Find-in-page" is an action that end-users take and expect to see the UI show feedback within a reasonable amount of time. If the event was a "notify after the fact" then I wouldn't have a problem, but because it allows for cancelability, I am concerned.

Hypothetically, a UA could just always ignore the `preventDefault()` and always show its own UI regardless. If a UA did this, I suspect you'd be disappointed because it wouldn't be enabling some of the scenarios proposed in the spec, right?

The workaround, for me, is to express to the platform the *intent* to cancel the find UI before the user actually invokes the action. This takes out the blocking aspect. Something like:

```js
// crappy example
navigator.commandeerFindInPage( { showui: false }, () => { /* show your own fancy find-in-page */ } );
// callback executed every-time user tries to find.
```


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/236#issuecomment-380620987