In this bug, I will be making window.external.AddSearchProvider a dummy function with a hidden preference to re-activate. This will land in 78. A follow-up bug will remove the associated code and preference in 79.

Background:

• The HTML Standard specifies this method as "must do nothing":
• Internet Explorer: This feature was supported in IE7-9 but deprecated in IE10+ and not present in Edge.
• Chrome: Changed to no-op in 54.
• Safari: No supported

Reasons: AddSearchProvider allows adding OpenSearch providers from a website page. This has been deprecated by the WHATWG, and IE and Chrome no longer support it. As far as I know it has never been supported on Mobile.

This API allows a website to put up unsolicited repeated prompts to users. It is vulnerable to potential DoS attacks.

For websites wanting to provide their own engines, the alternative is to include the <link rel="search"> tag, or to provide their own add-ons which add search engine providers.

Add-ons that use the API would no longer work. Of the two add-ons we have found that use the API, they are both ways of adding custom search engines. They both have small numbers of users. Whilst we acknowledge this will remove some functionality for users, we would encourage users to request that websites provide their own search integrations which would have the advantage of being maintained by the website, and being available to everyone.

Adding dev-doc-needed, at least this page will need updating: https://developer.mozilla.org/en-US/docs/Web/API/Window/external

Intent to unship is posted: https://groups.google.com/d/msg/mozilla.dev.platform/vSV-gg5621k/zOughoepBQAJ

It turns out bug 1503551 already added a pref for this, so we just need to flip it.

Try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=45c10b03a7337c31e1519f4acce16db5695a7133

The preference disables window.sidebar as well. Is it safe to remove it particularly during COVID-19? Some breaking changes are being postponed at this time. And Firefox 78 will be the next ESR.

(In reply to Kohei Yoshino [:kohei] from comment #6)

The preference disables window.sidebar as well. Is it safe to remove it particularly during COVID-19? Some breaking changes are being postponed at this time. And Firefox 78 will be the next ESR.

Oh, I thought I'd tested that, maybe it needed restart or something. Fix seems obvious though.

(In reply to Kohei Yoshino [:kohei] from comment #6)

The preference disables window.sidebar as well. Is it safe to remove it particularly during COVID-19? Some breaking changes are being postponed at this time. And Firefox 78 will be the next ESR.

To clarify, window.external.AddSearchProvider and window.sidebar.AddSearchProvider are exactly the same implementation. As far as I can tell this is just an old standards quirk.

In any case, as per the intent to unship, these are going to be changed to dummy functions, as per the spec. The earlier patch actually removed window.sidebar completely, so I've changed it to stop that.

I don't see an issue with disabling this now - it has been a month since the unship was logged with no significant/new issues raised. The functions will be dummies, so no exceptions will be thrown. It is unlikely that anyone would be relying on this day to day as search engines are generally a one-off setup. Plus it has been disabled on other browsers for ages already (as per the documentation). If they can't change the website to use meta tags for the open search engine, then worst case, they could use ESR and pref-flip it back on - we're not removing the back-end code until 79.

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

Posted a site compatibility note for the change.

I've updated:
https://wiki.developer.mozilla.org/en-US/docs/Web/API/Window/external
https://wiki.developer.mozilla.org/en-US/docs/Web/API/Window/sidebar

...to say that AddSearchProvider() does nothing, and updated the BCD table to say that this is true of Firefox from version 78.

Marking as dev-doc-complete, but please let me know if you need anything else.

When block size is initially indefinite but later was determined by the contain intrinsic
size, we calculate the track sizes using the contain intrinsic block size.

Backed out as requested.

Backed out for landing with wrong bug number: https://hg.mozilla.org/integration/autoland/rev/43e4aec47749f47e838b5627db8ab7282021ae5e

The extra patch is moving across to bug 1783006