Implement chrome.search
Categories
(WebExtensions :: General, enhancement, P5)
Tracking
(firefox111 fixed)
Tracking | Status | |
---|---|---|
firefox111 | --- | fixed |
People
(Reporter: gregp, Assigned: gregp)
References
Details
(Keywords: dev-doc-complete, Whiteboard: [addons-jira])
Attachments
(1 file)
Assignee | ||
Updated•2 years ago
|
Comment 2•2 years ago
•
|
||
I don't think this should be a duplicate. This is asking for a specific feature Chrome API.
(In reply to Mike Kaply [:mkaply] from comment #2)
I don't think this should be a duplicate. This is asking for a specific feature Chrome API.
- Support https://developer.chrome.com/docs/extensions/reference/search/#type-Disposition
- And maybe rename
browser.search.search
tobrowser.search.query
(for better browser compatibility?)
And also rename searchProperties.query
to searchProperties.text
.
Comment 4•2 years ago
|
||
Probably not rename, but add.
Should be easy to do since we have the existing API.
Comment 5•2 years ago
|
||
Unlike Chrome, Firefox's browser.search.search
method also supports the ability to select an engine: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/search/search
and a way to retrieve the search engines (including non-default ones): https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/search/get
Chrome's chrome.search.search
version has a disposition
method that's mutually exclusive with tabId
(defaulting to the current tab, optionally in a new tab or new window). Firefox's version does not have disposition
, and if tabId
is omitted a new tab is opened.
These differences are easy to reconcile. The question is whether we should support both or drop one of them. With MV3 around the corner, and the ease of making these changes, it would realistically not be difficult to implement a common API and deprecate the existing one in MV3.
Coincidentally, last week there was some discussion in the WECG on the search
API (https://github.com/w3c/webextensions/issues/330). It is unrelated to what's being requested here, but if desired we could consider working towards a common API that covers both versions of the API
Updated•2 years ago
|
Comment 6•2 years ago
|
||
Assignee | ||
Comment 7•2 years ago
|
||
Updated•2 years ago
|
Comment 8•2 years ago
|
||
I've discussed the idea of deprecation with my team. There were no very strong opinions either way.
An argument against deprecation of browser.search
+ replacement by browser.query
is that the browser.query
method is currently specified by Chromium without standardization. We'd have to add the "engine" property/feature to the browser.query()
method, but it is unclear whether the feature in that form could (ever) be compatible with Chromium.
While the implementation of browser.search.query
could make it easier for Chrome extensions to migrate to Firefox, the deprecation/removal of browser.search.search
would make it a bit harder to migrate from MV2 to MV3.
Given these issues and the small complexity of the current implementation, we decided to keep the existing method, and accept the new method without changes (i.e. without a new engine
property).
Assignee | ||
Comment 9•2 years ago
|
||
We'd have to add the "engine" property/feature to the browser.query() method, but it is unclear whether the feature in that form could (ever) be compatible with Chromium.
It is not obvious to me why that is. The current patch does include engine
support in search.query and I can't see how that's a problem unless Chromium introduces its own engine
property at a later date with different-enough-semantics to become incompatible with Firefox, which I do not foresee happening.
Given these issues and the small complexity of the current implementation, we decided to keep the existing method, and accept the new method without changes (i.e. without a new engine property).
That's a bummer, because I'd personally like to use disposition
alongside engine
in an extension I'm working on. If we can't add engine
to search.query, could we add disposition
to search.search instead?
Comment 10•2 years ago
|
||
I'm supportive of supporting disposition in search.search.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 11•2 years ago
|
||
Comment 12•2 years ago
|
||
This feature should be documented along with bug 1811274.
Thanks Greg for your patches!
Comment 13•2 years ago
|
||
bugherder |
Comment 14•2 years ago
|
||
BCD completed in Add BCD for search.query method and search.search disposition property #18903
Comment 15•2 years ago
|
||
MDN content updated in #24668
Description
•