1271537 - Provide ability to override "Find" (find in this page - Ctrl-F) and "find as you type" results for addons

Status: RESOLVED WORKSFORME

(WebExtensions :: Untriaged, defect)

Description

[YUKI "Piro" Hiroshi]

My addon "XUL/Migemo" https://addons.mozilla.org/en-US/firefox/addon/xulmigemo/ provided a custom "find in this page" behavior with regular expressions, based on nsIFind. The nsIFind service provides ability to find ranges from given ranges and a text. After XUL is ended, we need something to alter the service.

BTW, there is a working draft spec: RangeFinder API.

http://w3c.github.io/web-annotation/api/rangefinder/

It can be a basis of this idea. Or, if the API is implemented on Firefox natively, no extra WebExtensions API is required.

Comment 1

[YUKI "Piro" Hiroshi]

Recently I updated XUL/Migemo for Firefox 45 and Nightly 49.0a1, and I've realized that simple RangeFinder (or something) does not help addon authors around findbar no enough.

https://addons.mozilla.org/en-US/firefox/addon/xulmigemo/versions/

On lately versions 0.14.x, I override some methods of Finder.jsm to override behavior of the findbar.

http://mxr.mozilla.org/mozilla-esr45/source/toolkit/modules/Finder.jsm
https://github.com/piroor/xulmigemo/blob/master/modules/finder.jsm

And now I think that the really required API is: something mechanism to replace/register custom iterator, to get next/previous range for custom search results.

Actually, I successfully override find results (find, highlight all, and count of matched positions) by just replacing the method to create iterators for search results in each subframe.

https://github.com/piroor/xulmigemo/blob/7d294341632c8127f06d3904dfcf3f3f58883786/modules/finder.jsm#L180

The main "find" and "find as you type" feature is not based on the iterator, but I think we can rewrite the implementation to use same iterator.

Comment 2

[YUKI "Piro" Hiroshi]

Just ideas; if there is any API to replace/register custom iterators for search results, then it will make it possible to develop various unique addons around the findbar. For example: "find numbers larger/smaller than input", "find images in this page", and others.

Comment 3

[YUKI "Piro" Hiroshi]

On the other hand, if we have no such API, we must re-implement everything of the findbar itself. Actually, another addon "Fastest Search" (which is another implementation of regular expression search) seems doing it.

https://addons.mozilla.org/en-US/firefox/addon/fastest-search/

It includes findbar-compatible UI, selection-based  implementation to highlight matched terms, and so on - just to provide regexp-powered search results for webpages. I think that WebExtensions should not force something huge work like it to addon authors who just want to provide custom search results.

Comment 4

[YUKI "Piro" Hiroshi]

The API can implement addons to solve the bug 202251, bug 565552, and so on. Actually XUL/Migemo is also known as an addon to provide the feature "find in this page, ignoring phonetic modifiers like accents".

Comment 5

[Caitlin Neiman [:caitmuenster]]

To be discussed at 2/21 WebExtensions triage meeting. 

Agenda: https://docs.google.com/document/d/1H4sjnRFc87NZXZsM6XIgwWaoV2bdRFepiG28G7WzgPs/edit

Comment 6

[u462496]

Related: bug 1332144

Comment 7

[Shane Caraveo (:mixedpuppy)]

Yuki, Can you review the api in bug 1332144 and verify if it covers your use case.

Comment 9

[YUKI "Piro" Hiroshi]

(In reply to Shane Caraveo (:mixedpuppy) from comment #7)
> Yuki, Can you review the api in bug 1332144 and verify if it covers your use
> case.

It doesn't cover my case, because I take a different perspective. The API proposed at bug 1332144 seems an idea similar to these web API proposals:

 * https://www.w3.org/TR/findtext/
 * https://specs.webplatform.org/rangefinder/w3c/master/

In short, those proposals provide a way to call "find" feature from his application/addon.
On the other hand, my proposal provides a way to add switchable/programmable find provider for Firefox's find bar, like protocol handlers for new/known protocols, search provides (search plugin) on the web search bar/omnibar, and so on.

I think that such an objection is nonsense: "Why don't you build your custom find bar based on the finder API proposed at the bug 1332144?", because it is similar to: "Why you are going to implement omnibox API for WebExtensions? There are enough API to implement your custom location bar by your addon - IndexedDB, XMLHttpRequest, and others. You can build your custom location bar based on HTML <input> element as you like!"

Comment 10

[YUKI "Piro" Hiroshi]

(In reply to YUKI "Piro" Hiroshi from comment #9)
> I think that such an objection is nonsense: "Why don't you build your custom
> find bar based on the finder API proposed at the bug 1332144?", because it
> is similar to: "Why you are going to implement omnibox API for
> WebExtensions? There are enough API to implement your custom location bar by
> your addon - IndexedDB, XMLHttpRequest, and others. You can build your
> custom location bar based on HTML <input> element as you like!"

Additional descriptions about this point:

Ombibox APIs https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/omnibox is designed to "modify" behaviors of the location bar, because people don't want to add more and more custom location bars to Firefox(Chrome)'s toolbox and people just want to do everything from just single location bar.  

I say same thing about the find bar. I don't want to add "new, custom find bar" which replaces the Firefox's one. Instead, I hope to modify only find results of Firefox's find bar.

Comment 11

[u462496]

I am not completely clear on exactly all that Yuki as needing, but it sounds like we would want to access findbar.xml methods which could be done through gFindBar.  Nevertheless it sounds like Yuki has some very specific use cases.

Comment 12

[YUKI "Piro" Hiroshi]

(In reply to Kevin Jones from comment #11)
> I am not completely clear on exactly all that Yuki as needing, but it sounds
> like we would want to access findbar.xml methods which could be done through
> gFindBar.  Nevertheless it sounds like Yuki has some very specific use cases.

No, I don't need ability to full access to raw features of findbar.xml. Instead, required API is:

browser.find.addProvider('RegExp find', function(query, document) {
  var iterator = ... // you just need to create an iterator to return DOMRange
  return iterator;
});

Comment 13

[u462496]

I didn't mean to imply exposing all methods of findbar.xml.

Actually, the API being worked on in bug 1332144 does get an iterator of ranges.  At this point, I am not seeing a way to directly return the raw iterator to an extension for E10S since each case will be in the content process.  However what I am working on is maintaining an iterator for each tab which can be accessed just for that tab.

Perhaps if you could provide a boiled down version of the specific code which currently provides the functionality you want I can better see if there is a reasonable overlap in the API I am working on.

Comment 14

[YUKI "Piro" Hiroshi]

(In reply to Kevin Jones from comment #13)
> Actually, the API being worked on in bug 1332144 does get an iterator of
> ranges.  At this point, I am not seeing a way to directly return the raw
> iterator to an extension for E10S since each case will be in the content
> process.  However what I am working on is maintaining an iterator for each
> tab which can be accessed just for that tab.

Hmm, I forgot to think about e10s-firendly WE API...

> Perhaps if you could provide a boiled down version of the specific code
> which currently provides the functionality you want I can better see if
> there is a reasonable overlap in the API I am working on.

I'll try to redesign my proposal.

Comment 15

[YUKI "Piro" Hiroshi]

I've realized that what I really need is not APIs proposed at here, instead I need something mechanism to do synonyms search. Thus I've opened the bug 1353790 for the approach.

Comment 16

[Andy McKay]

Should we close this bug then?

Comment 17

[Andy McKay]

Based on comment 15.