Closed Bug 1804357 Opened 4 months ago Closed 2 months ago

Implement chrome.search

Categories

(WebExtensions :: General, enhancement, P5)

Desktop
All
enhancement

Tracking

(firefox111 fixed)

RESOLVED FIXED
111 Branch
Tracking Status
firefox111 --- fixed

People

(Reporter: gregp, Assigned: gregp)

References

Details

(Keywords: dev-doc-complete, Whiteboard: [addons-jira])

Attachments

(1 file)

Status: NEW → RESOLVED
Closed: 4 months ago
Duplicate of bug: 1352598
Resolution: --- → DUPLICATE

I don't think this should be a duplicate. This is asking for a specific feature Chrome API.

Status: RESOLVED → REOPENED
No longer duplicate of bug: 1352598
Resolution: DUPLICATE → ---

(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.

  1. Support https://developer.chrome.com/docs/extensions/reference/search/#type-Disposition
  2. And maybe rename browser.search.search to browser.search.query (for better browser compatibility?)

And also rename searchProperties.query to searchProperties.text.

Flags: needinfo?(mozilla)

Probably not rename, but add.

Should be easy to do since we have the existing API.

Flags: needinfo?(mozilla)

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

Whiteboard: [addons-jira]
See Also: → 1136131
Assignee: nobody → gp3033

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).

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?

I'm supportive of supporting disposition in search.search.

See Also: → 1811274
Severity: -- → N/A
Status: REOPENED → ASSIGNED
Priority: -- → P5
Blocks: 1811274
See Also: 1811274
Pushed by rob@robwu.nl:
https://hg.mozilla.org/integration/autoland/rev/e5a518427f13
Implement browser.search.query r=robwu,search-reviewers,Standard8

This feature should be documented along with bug 1811274.

Thanks Greg for your patches!

Keywords: dev-doc-needed
Status: ASSIGNED → RESOLVED
Closed: 4 months ago2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 111 Branch

BCD completed in Add BCD for search.query method and search.search disposition property #18903

MDN content updated in #24668

You need to log in before you can comment on or make changes to this bug.