Open Bug 1395009 Opened 7 years ago Updated 2 years ago

Find API - Introduce WebExtension events

Categories

(WebExtensions :: General, enhancement, P5)

enhancement

Tracking

(Not tracked)

People

(Reporter: ntim, Unassigned)

References

Details

(Whiteboard: [design-decision-deferred])

See bug 1332144 comment 27.

It would be nice to be able to hook in the following events:

- When the user has queried a search (browser.find.onQueryEntered ?)
Use case: add a scrollbar showing the position of each result when the user does Ctrl+F, types a search

- When the user moves up and down in the search (browser.find.onMoved/Highlight)
Use case: Add an extra highlight when the user moves up and down in the search


The callback of browser.find.onMoved/Highlight would take a resultId, which should be in sync with the one returned by browser.find.find();
Priority: -- → P3
Whiteboard: [findAPI]
Whiteboard: [findAPI] → [find]
When user types, the result is updated accordingly, would an onMove/onChange event sufficient?

And if the callback obtains current result and total number of results, we will be able to watch below general cases:

1. user start to type.
2. result not found.
3. moved to bottom, and wrapped to top.
Severity: normal → enhancement
Priority: P3 → P5
Whiteboard: [find] → [design-decision-needed]
Hi Tim, this has been added to the agenda for the WebExtensions APIs triage on May 15, 2018. Would you be able to join us? 

Here’s a quick overview of what to expect at the triage: 

* We normally spend 5 minutes per bug
* The more information in the bug, the better
* The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details

Relevant Links: 

* Wiki for the meeting: https://wiki.mozilla.org/WebExtensions/Triage#Next_Meeting
* Meeting agenda: https://docs.google.com/document/d/1Y_oYPldTT_kQOOouyJbC-8y3ASIizScLKFRhQfsDQWI/edit#
* Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision
Flags: needinfo?(aswan)
Whiteboard: [design-decision-needed] → [design-decision-deferred]
The talk during the triage meeting veered into discussing an API for extensions to replace the find backend, but I don't think that's what the reporter is looking for here (though please correct me if I'm wrong).

The use cases presented are about overlaying additional UI which we don't have a good solution for right now (see bug 1340930 for example).  Without that in place, nobody felt this was very compelling.  Have we overlooked something?
Flags: needinfo?(aswan)
The other case is having a sidebarAction that cycles along with the findbar results like Findbar Tweak provides.
Flags: needinfo?(aswan)
I'm not familiar with Findbar Tweak.  
Regardless, I fear that trying to allow extensions to augment but co-exist alongside the built-in find user interface is going to be difficult to do well, and especially difficult to maintain in the long run.  I think we would be much better off making it possible for extension authors to create their own find user interfaces.  That would entail things like addressing the overlay bug I referenced before (which is on the roadmap) and potentially allowing extensions to register commands for the default find key binding.
Flags: needinfo?(aswan)
(In reply to Andrew Swan [:aswan] from comment #5)
> I'm not familiar with Findbar Tweak.  
> Regardless, I fear that trying to allow extensions to augment but co-exist
> alongside the built-in find user interface is going to be difficult to do
> well, and especially difficult to maintain in the long run.  I think we
> would be much better off making it possible for extension authors to create
> their own find user interfaces.  That would entail things like addressing
> the overlay bug I referenced before (which is on the roadmap) and
> potentially allowing extensions to register commands for the default find
> key binding.

That would be fine with me, but there's no current way to override the default findbar.
(In reply to :ntim (busy until May 25th) from comment #6)
> That would be fine with me, but there's no current way to override the
> default findbar.

Is there something more to this than allowing extensions to use the commands API to override the default search hotkey?  Extensions could put their UI in a sidebar or popup right now and could use an overlay when that bug is addressed (which they'll presumably need to highlight find results in-content anyway)
Product: Toolkit → WebExtensions
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.