Open Bug 1504338 Opened 6 years ago Updated 2 years ago

Provide an alternative to AddSearchProvider for extensions

Categories

(Firefox :: Search, enhancement, P3)

enhancement

Tracking

()

People

(Reporter: evilpie, Unassigned)

References

Details

Bug 1503551 disabled window.external.AddSearchProvider. However AddSearchProvider was the only reasonable convenient way of offering people to install new search engines.

As used in my extension: https://addons.mozilla.org/en-US/firefox/addon/add-custom-search-engine/ or https://addons.mozilla.org/en-US/firefox/addon/search-engines-helper/

It would be great to offer an alternative API. Or maybe allow extensions to continue using AddSearchProvider.
No longer depends on: 1503551
I think the search team needs to make a policy decision here before we can do any extensions work, re-classifying to put it on their radar.
Component: General → Search
Product: WebExtensions → Firefox
Summary: Provide an alternative to AddSearchProvider → Provide an alternative to AddSearchProvider for extensions
Depends on: 1503551
Blocks: 1503551
No longer depends on: 1503551
Seems like it should be OK to let webextensions install engines...  That decision is all that's needed by the search team, right?  The APIs are already there if the webextensions side wants to hook into them.  Mike, what do you think?
Flags: needinfo?(mozilla)
Priority: -- → P3
Blocks: 1512047
No longer blocks: 1503551
> Seems like it should be OK to let webextensions install engines...  That decision is all that's needed by the search team, right?  The APIs are already there if the webextensions side wants to hook into them.  Mike, what do you think?

We're putting AddSearchProvider back for now. We don't have a good long-term story here.

As far as providing an API for WebExtensions, that would be up to the search PM and WebExtensions PM to decide.
Flags: needinfo?(mozilla)

(In reply to Mike Kaply [:mkaply] from comment #3)

We're putting AddSearchProvider back for now. We don't have a good long-term story here.

Has it been removed again? I'm on Dev Edition and just found I was unable to add another engine from mycroftproject.com (I have many already installed), and installing the only relevant add-on I can find did not help.

Toggling pref dom.sidebar.enabled back to true fixed it.

(In reply to Roy Orbison from comment #4)

(In reply to Mike Kaply [:mkaply] from comment #3)

We're putting AddSearchProvider back for now. We don't have a good long-term story here.

Has it been removed again?

Yes, this was announced and discussed here and that was noted in various related bugs. Unfortunately I missed commenting in this bug.

To note at the end of the thread, the customisation of search engines (e.g. user-additions) is currently something we're discussing amongst the search team and I'd expect us to have a better idea of where we want to go in a couple of months.

That's disappointing. Having a good feature disappear, essentially because it's poorly promoted, disadvantages Firefox. I really like being able search things on specific sites without telling privacy-violating, tax-evading mega corporations every detail about me, and having those tools keep themselves updated. I know that's not being dropped completely from Firefox, but previous OpenSearch support was great.

Citing parity with Chrome is absurd because using other search engines represents a conflict of interest to Google. The DoS security aspect seems tenuous because (a) I've never once encountered a malicious search engine trying to use this API, and (b) if it is an issue, its invocation could be limited to genuine user-interaction events (in the same vein as preventing media autoplay) and have the same "prevent this site from creating more pop-ups" logic as alert().

Why not extend the existing <link> functionality to <a> tags (attributes are compatible) so engines may be added from user interaction without being relegated to hidden/subtle browser UI?

<a rel="search"
      type="application/opensearchdescription+xml"
      title="searchTitle"
      href="pluginURL">Add a this site to your search providers</a>

(In reply to Roy Orbison from comment #7)

I really like being able search things on specific sites without telling privacy-violating, tax-evading mega corporations every detail about me, and having those tools keep themselves updated.

Most OpenSearch definitions I've seen don't actually use the update functionality, so they wouldn't be keeping up to date. They can still provide their own engines via the <link rel="search">.

Citing parity with Chrome is absurd because using other search engines represents a conflict of interest to Google.

It has already been proven lots of times in the past that having differing implementations across browser hurts the open internet.

The DoS security aspect seems tenuous because...

That was just one of the contributing reasons.

Why not extend the existing <link> functionality to <a> tags (attributes are compatible) so engines may be added from user interaction without being relegated to hidden/subtle browser UI?

Sites can already do this by providing WebExtensions with search engines defined within them. Hence sites still have two methods of providing engines.

In any case, this is getting off-topic for this bug as this is about allowing extensions to define custom engines. If you have other concerns please discuss in the previously cited thread.

(In reply to Roy Orbison from comment #7)

Why not extend the existing <link> functionality to <a> tags (attributes are compatible) so engines may be added from user interaction without being relegated to hidden/subtle browser UI?

Sites can already do this by providing WebExtensions with search engines defined within them. Hence sites still have two methods of providing engines.

To clarify your point, are you stating that Mozilla's current alternative to the (minimal) browser UI is for individual websites to offer & maintain a WebExtension in order to install OpenSearch engines?

(In reply to Mark Banner (:standard8) from comment #8)

Most OpenSearch definitions I've seen don't actually use the update functionality, so they wouldn't be keeping up to date. They can still provide their own engines via the <link rel="search">.

There's 24000 that have update defined here if you want to look a bit harder:
https://mycroftproject.com/
(Yes, self promotion disclaimer...)

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.