1549145 - Extension using chrome_override_settings to set default search re-enabled, but search default not restored w/Study fix (Ecosia)

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, defect)

Description

[Philip]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

1. Install Ecosia extension setting Ecosia as my default search engine https://addons.mozilla.org/en-US/firefox/addon/ecosia-the-green-search/?src=search
2. All extensions were disabled due to certificate issue on 05-04-2019 see https://bugzilla.mozilla.org/show_bug.cgi?id=1548973
3. All extensions were re-enabled through studies hotfix-update-xpi-signing-intermediate-bug-1548973

OS: MacOS 10.14.04
Firefox version: 66.0.3 (64-bit)

Actual results:

The search engine entry Ecosia was not restored as the default.

Expected results:

With reactivating the extension the search engine entry should have been restored as the default since this was the single reason why I installed the extension.

Comment 1

[vleet]

I confirm this issue with StartPage default search engine Addon. The re-enabled extension did not apply the search engine.

Comment 2

[Bogdan Maris, Desktop QA]

So we saw that Ecosia is restored as a default search engine after applying the hotfix BUT only if we set it as default from the prompt that appears (in navigation bar) after installing the addon. If we set Ecosia as default search from about:preferences then indeed after applying the hotfix the search engine will remain the default one "google".

Comment 3

[Andrew Swan [:aswan]]

I think that what is being observed is consistent with the design for extensions and default search engines.

Specifically, that design is that at the moment a user installs an extension that sets the default engine, they are presented with a prompt. This is the one and only time when that search engine can become the default. If the user declines the prompt or if they change their default in about:preferences, or if they disable the extension (even if they later re-enable it), that search engine stops being the default. The state of a particular extension is kept in the extension settings store, but all the scenarios described in the previous sentence result in the same state: the default search setting for the extension is labeled as disabled.

That last case (disabling and re-enabling) is effectively what happened here. Of course, the disabling and re-enabling was not done deliberately by users. But, due to the way this was designed, we don't have any state anywhere recording the fact that the engine used to be the user's opted-in default.

There's no simple technical fix here, I think at this point product needs to weigh in.

Comment 4

[Andrew Swan [:aswan]]

To be clear, comment 3 is about an extension-provided search engine automatically becoming the default. Extensions can always add a new search engine to the list of engines the browser knows about and the user can always go into about:preferences and choose a default. This bug is about extension-provided engines become the default without the user touching about:prefs

Comment 5

[Philip]

Philip here from Ecosia. Thank you for looking into this, let me briefly share our perspective:

When users install our extension the default search engine is set to Ecosia. That's how the extension is described and users are asked in an additional popup if they want that change after installing, which they have confirmed with yes. So previously active extension users search with Ecosia by default. It's the functionality they want, expect and are used to.

Therefore it is crucial that those users get this functionality, which was broken due to the certificate issue, back. To make a suggestion a feasible way of fixing this would be to set the search engine setting to Ecosia for all Firefox users with an active Ecosia extension and not other search extension installed.

We hope that this can be resolved soon. Please let us know if we can be of any support.

Comment 6

[Alex J]

Any new developments in the fixing of this bug?

Comment 7

[Alex J]

@aswan do you know if this is still being worked on?

Comment 8

[Mike Connor [:mconnor]]

Hi all, apologies for the delay in responding on this issue, we were waiting for enough data to fully determine scope/impact.

Based on the analysis of Telemetry before and after, there's currently no significant effect on the number of users or searches associated with WebExtensions (both as a whole and some of the add-ons named in this bug report). We believe that very few users were actually affected, and of those, almost all chose to restore their desired default through the Firefox search preferences. For those who didn't, we have no way to tell when they switched to another default, and we know that a significant number of users with this class of add-ons were not using those added engines as default before May. That proportion is about the same before and after. This means any solution along the line of comment 5 would negatively impact a much larger number of users who weren't using those engines as default before the incident.

Given that we've observed little to no impact, that there's no way to target a fix to only touch affected users, we plan to close this bug as WONTFIX.

Comment 9

[Philip]

Hi, thank you for taking the time to look into this and sharing the update. Although it is not the outcome we had hoped for we can understand the reasoning. We can confirm regarding numbers from our side that luckily not a lot of users seem to have been permanently disabled. We can't exactly reconstruct from our side what happened but it seems that not as many users as initially thought were disabled and some must have manually re-enabled their extension and restored their search engine setting.

What this incident shows from our point of view that the current integration of WebExtensions and the search engine setting is not optimal and quite brittle. We would hope that there will be capacity soon to improve this.