https://developer.chrome.com/docs/extensions/reference/search/

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.

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.

Probably not rename, but add.

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

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

SEE ALSO:
https://bugzilla.mozilla.org/show_bug.cgi?id=1136131

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.

This feature should be documented along with bug 1811274.

Thanks Greg for your patches!

https://hg.mozilla.org/mozilla-central/rev/e5a518427f13

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

MDN content updated in #24668