Closed Bug 1268401 Opened 8 years ago Closed 6 years ago

Add APIs to manage search engines for the web search bar/location bar

Categories

(WebExtensions :: Frontend, defect, P3)

Product:
WebExtensions
Component:
Frontend
Type:
defect

Tracking

(firefox49 affected)

Status:
RESOLVED DUPLICATE of bug 1428948
Tracking Flags:
Tracking Status
firefox49 --- affected

People

(Reporter: yuki, Assigned: kev)

References

(Blocks 2 open bugs)

Details

(Whiteboard: triaged) 

For enterprise use, needless default search engines are expected to be disabled, and sometimes custom search engines are needed to be installed by default. Currently we need to control search engines via nsIBrowserSearchService from an addon to do it. After WebExtensions, I need something to alter the feature.

Of course, non-WebExtensions solution (new secret preferences to do it, or new configuration entries in distribution.ini) will also help me.
Whiteboard: [design-decision-needed]triaged
I think the API can be appear like APIs to control tabs, like:

chrome.searchengines.query() // list search engines
chrome.searchengines.get() // get one engine
chrome.searchengines.install() // add new search engine
chrome.searchengines.create() // add new search engine from scratch without XML file - I think this will help us to generate search engines with different parameters easily (for example, different trees in dxr.mozilla.org)
Blocks: webextensions-additional-apis
Summary: Add APIs to manage search engines in the web search bar/location bar → Add APIs to manage search engines for the web search bar/location bar
Component: WebExtensions: Untriaged → WebExtensions: Frontend
Priority: -- → P3
I tried to port https://addons.mozilla.org/en-US/firefox/addon/add-to-search-bar/ to a WebExtension but this bug is a blocker for it.
Hello, my Search Buttons Bar extension requires API to query user's Search engines. As a WebExtension I didn't find any working solutions to achieve it. I'm currently using the nsIBrowserSearchService.

https://addons.mozilla.org/addon/searchbuttonsbar/
Flags: needinfo?(kev)
I don't see this as a high priority currently, but agree search services need review, and should include the search team. Search is frequently targeted by browser hijackers, and the policy around search needs to be reviewed, updated, and surfaced in the product. Off the top I don't see querying and/or using existing search services to present challenges, but there do need to be better user controls in place for any kind of modification outside that. This may also be impacted by work on platform, search, front-end, and other components, and it makes sense to get more input.

I'll add this to my backlog, and will try to get a rough proposal out before the holidays start in earnest.
Flags: needinfo?(kev)
As Qwant partnering closely with Mozilla, we are looking for this bug to move forward. Our current extension is not compatible with Electrolysis and this bug is missing for us to migrate our extension to WebExtensions. Any chance to prioritize this as high ?
webextensions: --- → ?
Assignee: nobody → kev
I there, I also require a WebExtensions API to access the browser's search engines (I use nsIBrowserSearchService currently), so this would make it possible to port my add-on. I'm the developer of Swift Selection Search:
https://addons.mozilla.org/en-US/firefox/addon/swift-selection-search
Could it be possible to add the ability to clear the search bar text on the API ?
Shouldn't 

chrome.searchengines.setDefault() // set one engine as default

be part of the API
(In reply to Tobias Mueller from comment #11)
> Shouldn't 
> 
> chrome.searchengines.setDefault() // set one engine as default
> 
> be part of the API

There's Bug 1301315 for this.
(In reply to Tim Nguyen :ntim from comment #12)
> There's Bug 1301315 for this.
Afaik this bug handles setting via manifest file only.
What about if an extension wants manage search engines? Or provide a setting to change the default?
(In reply to Tobias Mueller from comment #13)
> Or provide a setting to change the default?

Is the UI in the Firefox preferences not enough to set the default? I don't expect users to need to change their default engines frequently.
The UI in Firefox makes it very simple for the user to change defaults. At this time, we don't plan on adding the capability to set the search default via an extension with the WebExtensions API. 


(In reply to Tobias Mueller from comment #13)
> (In reply to Tim Nguyen :ntim from comment #12)
> > There's Bug 1301315 for this.
> Afaik this bug handles setting via manifest file only.
> What about if an extension wants manage search engines? Or provide a setting
> to change the default?
Will there be an API to get all the details (icon, prefix URL and search engine name) for the current (default) search engine?
See bug 1301315 for query details. 

(In reply to Geoffrey De Belie (Smile4ever) from comment #16)
> Will there be an API to get all the details (icon, prefix URL and search
> engine name) for the current (default) search engine?
webextensions: ? → ---
Getting the default search engine would help with an extension wishing to cleanly assign the search provider itself in it's own container, as per: https://github.com/mozilla/testpilot-containers/issues/434
Whiteboard: [design-decision-needed]triaged → triaged
See Also: → 1352598
Blocks: 1311472
I'm totally new to developing ffx extensions and I wanted to create a web extension that uses the search engines from the search bar. I encountered a lot of trouble trying stuff from the MDN only to finally discover that you can't import nsIBrowserSearchService when using the WebExtensions API. I'm surprised to see that this has been a pending issue for a year now despite being very blocking for many extension developers. Can somebody please explain what is holding back firefox developers from unblocking the situation? Is the issue technical or political? I've been a encouraging donator for the further development of firefox, but this is a bit disappointing!
(In reply to Olivier de Broqueville from comment #19)
> I'm totally new to developing ffx extensions and I wanted to create a web
> extension that uses the search engines from the search bar. 

I think you want bug 1352598.

>Can somebody please explain what is holding back firefox developers from unblocking the situation?

Changing the search engines (unlike just querying them, see the linked bug) is controversial because changing the default search engine is one of the most common hijacking attacks against browsers.
(In reply to Gian-Carlo Pascutto [:gcp] from comment #20)
> Changing the search engines (unlike just querying them, see the linked bug)
> is controversial because changing the default search engine is one of the
> most common hijacking attacks against browsers.

Thank you for your explanation, Gian-Carlo. Personally, I'm not looking for a way to modify the default search engine. I wanted to create a contextual search extension, which integrates with Firefox's search bar. Right-clicking on selected text in a web page would present a user with a contextual menu listing all the search engines he or she uses in the search bar. Unfortunately, with WebExtensions, I currently have no way of reading the list of search engines available in the search bar. For the mean time, I've resorted to creating a pre-specified list of search engines a user has to choose from, but I understand some users would preferably define their own search engines.
Following this bug for "Duplicate Tabs Closer" extension compatibility.
OK, so looking at this more, what's being asked for is a simple "query search engines" API which I think is a good idea. I think there are good usecases for this (I've already found some).

I'm going to put together a spec and see what folks think. It's basically querying engines, including which is the default and possibility building a submission URL with an engine (so you have the possibility of executing a search in your addon).
Mike, thanks for looking into it. 

Can you please also include the icon (e.g. base64 URI) as a retrievable property, e.g. so we can use it for menu items or whatever other use-cases people have? This is what nsISearchEngine currently provides. I'm looking for my add-on to provide the glue that bridges the search plugin API (this bug) and the change implemented in bug 1321544.

In fact, I guess this bug is essentially asking for a read-only exposed interface over nsIBrowserSearchService.getVisibleEngines() and nsISearchEngine.

A further consideration... Currently my add-on (and probably others) implements search via nsISearchSubmission, which permits sending data over POST. I assume the search box in the toolbar still does this as well, as that's where I essentially duplicated the implementation from originally. It would be nice if that behaviour can be preserved, but I don't know if that's just scope-creeping this bug or whether there should be a follow-up to allow this via the tabs API if not already possible.

Quick reference links:
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsISearchEngine
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIBrowserSearchService
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsISearchSubmission

Screenshot of my add-on for context (pun not intended):
https://www.basson.at/images/addons/contextsearch.png
Depending on what you're planning to implement under this bug, it may be worth closing off bug 1352598 as a dupe of this one?
(In reply to Ben Basson from comment #25)
> Depending on what you're planning to implement under this bug, it may be
> worth closing off bug 1352598 as a dupe of this one?

I really would prefer Mike doing its idea for 1352598, and leaving this bug to include, at least, the capacity to add engines programmatically, so another different set of add-ons, as "Add to Search Bar", can be ported.
(In reply to Mike Kaply [:mkaply] from comment #23)
> OK, so looking at this more, what's being asked for is a simple "query
> search engines" API which I think is a good idea. I think there are good
> usecases for this (I've already found some).
> 
> I'm going to put together a spec and see what folks think. It's basically
> querying engines, including which is the default and possibility building a
> submission URL with an engine (so you have the possibility of executing a
> search in your addon).

Please see https://github.com/Smile4ever/webext-experiment-searchengines for the research I did. The webextension experiment is far from finished, but it provides some clues on which data is available in Firefox and other OpenSearchDescription implementations of search engines.
(In reply to Geoffrey De Belie (Smile4ever) from comment #27)
> (In reply to Mike Kaply [:mkaply] from comment #23)
> > OK, so looking at this more, what's being asked for is a simple "query
> > search engines" API which I think is a good idea. I think there are good
> > usecases for this (I've already found some).
> > 
> > I'm going to put together a spec and see what folks think. It's basically
> > querying engines, including which is the default and possibility building a
> > submission URL with an engine (so you have the possibility of executing a
> > search in your addon).
> 
> Please see https://github.com/Smile4ever/webext-experiment-searchengines for
> the research I did. The webextension experiment is far from finished, but it
> provides some clues on which data is available in Firefox and other
> OpenSearchDescription implementations of search engines.

This looks better than a spec. Did you consider going through the official process to try to get this into Firefox?

See:

http://webextensions-experiments.readthedocs.io/en/latest/uplifting.html
from another bug:
November 14 WebExtensions
APIs triage meeting.

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/Add-ons/Contribute/Triage
* Meeting agenda:
https://docs.google.com/document/d/1g3RMfKZ3671NcusMqkoOiKwfPekRe-VI7Rzqxo6F_Ao/edit#
* Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision
(In reply to Worcester12345 from comment #29)
> from another bug:
> November 14 WebExtensions
> APIs triage meeting.
> 
> 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/Add-ons/Contribute/Triage
> * Meeting agenda:
> https://docs.google.com/document/d/1g3RMfKZ3671NcusMqkoOiKwfPekRe-
> VI7Rzqxo6F_Ao/edit#
> * Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision

Just went to the page, and it says next meeting is January 10.  Are these meetings not happening any more? That said, if they are still happening, it would be nice if this bug could get on the agenda. Thanks.
See previous question and note outdated wiki.
Flags: needinfo?(mozilla)
I was going to put together a spec, but after looking at :

https://github.com/Smile4ever/webext-experiment-searchengines

I thought Geoffrey might want to spearhead the process.

Geoffrey, is this something you are interested in making happen?
Flags: needinfo?(mozilla) → needinfo?(geoffreydebelie)
Can you get this into the next "triage" meeting agenda? When is that meeting? Thanks.
Hi all, we're going to bring this back into the triage meeting on March 6, 2018. Mike, it would be awesome if you could update the bug once you've confirmed the current plan. 

Relevant links: 
Agenda: https://docs.google.com/document/d/1n-Cbk3d6j394mObWPMhQsfIyHIL08RhC_IEV2QBV1x8/edit#
Wiki: https://wiki.mozilla.org/WebExtensions/Triage
I'm honestly really confused at this point because bug 1352598 seems to be approved and has an initial implementation of the query search engine APIs.

I'm going to remove this from the triage meeting for today while I try to figure out what the actual plan is.
(In reply to Mike Kaply [:mkaply] from comment #35)
> I'm honestly really confused at this point because bug 1352598 seems to be
> approved and has an initial implementation of the query search engine APIs.
> 
> I'm going to remove this from the triage meeting for today while I try to
> figure out what the actual plan is.

Please don't. I think these are two separate things. Isn't this the whole point of bringing it to that meeting?
;-)
Thanks.
> Please don't. I think these are two separate things. Isn't this the whole point of bringing it to that meeting?

We have no plans to allow adding search engine dynamically via WebExtensions. We've had too many problems with hijacking.

Specifying engines via manifest.json is the only way to add engines.

I thought what we were discussing at the triage was the API for querying/using engines.
I'm very sorry I missed the triage meeting...

A half of the original motivation of this proposal is already covered by the bug 1428948. On company use, policies (Policy Engine) is a reasonable solution to do that. The rest half is: removing search engines via Policy Engine. Some system administrators want to remove Amazon from default list of search engines shown in the location bar (or the search bar), and another want to remove Google.
> The rest half is: removing search engines via Policy Engine. Some system administrators want to remove Amazon from default list of search engines shown in the location bar (or the search bar), and another want to remove Google.

This is something we plan for the policy engine.
We're not going to expand WebExtensions capabilities in this area, duplicating to the policy engine bug.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Clearing the needinfo requested in the wrong bug. Correct bug for the needinfo request would be  https://bugzilla.mozilla.org/show_bug.cgi?id=1352598
Flags: needinfo?(geoffreydebelie)
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.