Add the onProviderStartQuery event API
Categories
(Firefox :: Address Bar, task, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox69 | --- | fixed |
People
(Reporter: mikedeboer, Assigned: adw)
References
Details
Attachments
(1 file)
For more info, see the design doc over at https://docs.google.com/document/d/11c-OTsscmArnqL02Kq1TUPKtkHl4avmC3pDdSJDC6JI/edit
Comment 1•2 years ago
|
||
We should probably also handle cancel
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 2•2 years ago
|
||
Marco, this is still a WIP -- could you please provide some initial feedback? Please resign the review or request changes when you're done.
There are several things going on.
(1) This adds a browser.urlbar.onQueryStarted event that's fired after onQueryReady, as the query starts. Listeners in extensions should return an array of Result objects. This seems like a simple but sufficient way for extension providers to add their results to a query.
It's not possible to pass functions across the API boundary, and it's not possible for custom webextension types (like our QueryContext type) to have methods, just properties afaict -- which makes an addResult
callback or QueryContext.addResult
method not possible.
I considered adding a browser.urlbar.addResults function. It would take a QueryContext ID. But I'm not convinced that extensions really need to add their results in a chunked manner. It seems sufficient to ask them to return all their results at once. And in that case, a new event whose listeners return a list of results seems simpler.
I also considered having onQueryReady listeners return a complex object that somehow both indicates their behavior (as they do currently) plus returns results, but that's more complex.
(2) I made the onQueryReady event optional -- i.e., extensions don't have to listen for it. Extension providers default to "active". That seems reasonable to me. If I'm adding a urlbar extension, I would expect my results to show up by default. If I want some other behavior, then I can listen for onQueryReady and return something else.
Therefore an extension's provider is created the first time it calls onQueryReady or onQueryStarted.
(3) Internally, I removed the extension listeners map from UrlbarProvidersManager. Instead, extension listeners are added directly to UrlbarProviderExtension instances, and then UrlbarProvidersManager just loops through extension providers, not a separate map of listeners. That's effectively how startQuery
on each provider has always worked (and that's where I got the idea from) -- when we start a query, we loop through providers and call startQuery
on them. (And now that this patch adds the onQueryStarted event, startQuery
calls the onQueryStarted listeners.)
This also allowed me to move the timeout (SkippableTimer) handling to UrlbarProviderExtension so that it can be used for my new onQueryStarted event, too.
(4) Since UrlbarProviderExtension is getting a little bigger, I moved it to its own file.
Updated•2 years ago
|
Assignee | ||
Comment 3•2 years ago
|
||
Updated•2 years ago
|
Assignee | ||
Comment 4•2 years ago
|
||
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 5•2 years ago
|
||
Assignee | ||
Comment 6•2 years ago
|
||
One more try push before landing: https://treeherder.mozilla.org/#/jobs?repo=try&revision=6f55a93da84b00772f950faa739a9a554cf91916
Pushed by dwillcoxon@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d5b769e2a3f5 Quantumbar extension API: Add onBehaviorRequested, onResultsRequested, onQueryCanceled, and Result type, and change some internals. r=mak,mixedpuppy
Comment 8•2 years ago
|
||
bugherder |
Description
•