Re: Browser search API

On Tue, Dec 3, 2013, at 6:48, Mitar wrote:
> And there are real use cases. For example, go to some long document in
> Google Docs and invoke browser search by going through menu (Edit ->
> Find or something similar). You will see that it does not work except
> for the current document page. It does not find pages which are
> further down the document, because they have not yet been rendered. If
> you press ctrl-f, Google Docs intercepts this and provides you with
> their own search interface which does work across whole document. This
> is a bit
> hackish in my opinion because it would be better that you would be
> able to use known interface (especially important on mobile devices
> where you are not pressing ctrl-f, and some custom interface might not
> be as well integrated as native one - for example, native one could
> provide voice search for free (as no time needed to implement it)).
> And that it would work across whole document. Google Docs is just an
> example, any dynamic and rich document viewer has this issue, Mozilla
> pdf.js for example as well.

So, it's not clear to me why the inability to search in unloaded pages
will be fixed by intercepting the system find in page unless let the UA
doing the search but then it is no longer clear why you want to know
that a search is actually happening. (This said, if the text is not
loaded, it is not clear how the UA would be more able to search unloaded
content.)

I agree with the native UI issue but wouldn't the page still need a way
to tell the UA that it wants to perform the search itself? In that case,
the idiomatic way to do that is to cancel an event. But I feel like I am
missing something here. How do people use window.getSelection()?

--
Mounir

Received on Wednesday, 4 December 2013 14:25:48 UTC