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

RESOLVED WORKSFORME

Status

RESOLVED WORKSFORME
3 years ago
4 months ago

People

(Reporter: yuki, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk

Firefox Tracking Flags

(firefox49 affected)

Details

(Whiteboard: [design-decision-needed] triaged)

(Reporter)

Description

3 years ago
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.
(Reporter)

Updated

3 years ago
Blocks: 1215059
(Reporter)

Updated

3 years ago
Summary: Provide ability to get DOM Range for specified text in a webpage without selection (like RangeFinder) → Provide ability to find and get DOM Range for specified text in a webpage without selection (like RangeFinder)

Updated

3 years ago
Whiteboard: [design-decision-needed] triaged
(Reporter)

Comment 1

2 years ago
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.
Summary: Provide ability to find and get DOM Range for specified text in a webpage without selection (like RangeFinder) → Provide ability to override "Find" (find in this page - Ctrl-F) and "find as you type" results for addons
(Reporter)

Comment 2

2 years ago
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.
(Reporter)

Comment 3

2 years ago
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.
(Reporter)

Comment 4

2 years ago
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".
To be discussed at 2/21 WebExtensions triage meeting. 

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

Comment 6

2 years ago
Related: bug 1332144
Flags: needinfo?(mixedpuppy)
Yuki, Can you review the api in bug 1332144 and verify if it covers your use case.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(mixedpuppy) → needinfo?(yuki)
Resolution: --- → DUPLICATE
Duplicate of bug: 1332144

Updated

2 years ago
Duplicate of this bug: 1341057
(Reporter)

Comment 9

2 years ago
(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!"
Status: RESOLVED → REOPENED
Flags: needinfo?(yuki)
Resolution: DUPLICATE → ---
(Reporter)

Comment 10

2 years ago
(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

2 years ago
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.
(Reporter)

Comment 12

2 years ago
(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

2 years ago
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.
(Reporter)

Comment 14

2 years ago
(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.
(Reporter)

Comment 15

2 years ago
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

2 years ago
Should we close this bug then?

Comment 17

a year ago
Based on comment 15.
Status: REOPENED → RESOLVED
Last Resolved: 2 years agoa year ago
Resolution: --- → WORKSFORME

Updated

4 months ago
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.