Closed
Bug 1271537
Opened 8 years ago
Closed 7 years ago
Provide ability to override "Find" (find in this page - Ctrl-F) and "find as you type" results for addons
Categories
(WebExtensions :: Untriaged, defect)
WebExtensions
Untriaged
Tracking
(firefox49 affected)
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
firefox49 | --- | affected |
People
(Reporter: yuki, Unassigned)
References
Details
(Whiteboard: [design-decision-needed] triaged)
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•8 years ago
|
Blocks: webextensions-additional-apis
Reporter | ||
Updated•8 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•8 years ago
|
Whiteboard: [design-decision-needed] triaged
Reporter | ||
Comment 1•8 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•8 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•8 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•8 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".
Comment 5•8 years ago
|
||
To be discussed at 2/21 WebExtensions triage meeting. Agenda: https://docs.google.com/document/d/1H4sjnRFc87NZXZsM6XIgwWaoV2bdRFepiG28G7WzgPs/edit
Related: bug 1332144
Updated•8 years ago
|
Flags: needinfo?(mixedpuppy)
Comment 7•8 years ago
|
||
Yuki, Can you review the api in bug 1332144 and verify if it covers your use case.
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(mixedpuppy) → needinfo?(yuki)
Resolution: --- → DUPLICATE
Reporter | ||
Comment 9•8 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•8 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•8 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•8 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•8 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•7 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•7 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•7 years ago
|
||
Should we close this bug then?
Comment 17•7 years ago
|
||
Based on comment 15.
Status: REOPENED → RESOLVED
Closed: 8 years ago → 7 years ago
Resolution: --- → WORKSFORME
Updated•6 years ago
|
Product: Toolkit → WebExtensions
You need to log in
before you can comment on or make changes to this bug.
Description
•