1577792 - An incorrect message about a search engine being set as default is displayed after having been blocked

Status: RESOLVED WORKSFORME

(Firefox :: Search, defect, P3)

Description

[Daniel Bodea [:danibodea]]

Attachment: incorrect message displayed after retreivint blocklist and search engine is blocked.png

Note

• When a search engine is been set as default, and then it gets blocked by the Remore Search Engine Blocklisting feature, an incorrect message remains displayed in about:preferences#search that says that the manually installed search engine is still your default one.

Affected versions

• Nightly v70.0a1 from 2019-08-29
• Beta v69.0 RC
• Release v68.0.2

Affected platforms

• all

Steps to reproduce

1. Install Ecosia search engine extension:
   https://addons.mozilla.org/en-US/firefox/addon/ecosia-the-green-search/?src=search
2. Set it as the default search engine via the door hanger after install.
3. Add "ecosia.org" as a string to block on the "submission-urls" blocklist identifier;
4. Install the "Remote-settings-devtools" extension;
5. Open extension menu, switch to staging, clear all data and poll server.
   Now the Ecosia search engine should be blocked.
6. Observe the Search section of about:preferences.

Expected result

• No confusing messages should be displayed.

Actual result

• Incorrect message is displayed: "An extension, Ecosia - The search engine that plants trees, has set your default search engine."

Additional notes

• The same message remains incorrectly displayed even after browser restart.

Comment 1

[Shane Caraveo (:mixedpuppy)]

The issue here is very similar to the problem with homepage_overrides in bug 1578381. A preference that is currently controlled by an extension is getting changed directly rather than (or in addition to) using ExtensionSettingsStore.

We're adding search settings to the setting store[1][2], but it is not being updated when the search service is removing the extension (or search provider, not sure what it's doing). Whereever that removal is happening, we should make sure that ExtensionSettingsStore.removeSetting is also called.

If the extension is being entirely removed, this would probably be fixed by using AddonManager to remove the extension.

[1] https://searchfox.org/mozilla-central/rev/05db7b82d5a4adaa8b36ec6f4fd1715f6fd7885b/browser/components/extensions/parent/ext-chrome-settings-overrides.js#475
[2] https://searchfox.org/mozilla-central/rev/05db7b82d5a4adaa8b36ec6f4fd1715f6fd7885b/browser/components/extensions/parent/ext-chrome-settings-overrides.js#431

Comment 2

[Mark Banner (:standard8)]

To clarify, for both home page and search engines, we're only blocking the specific piece of functionality for the add-on matching the ignore list. We're not causing the add-on to be removed.

(In reply to Shane Caraveo (:mixedpuppy) from comment #1)

The issue here is very similar to the problem with homepage_overrides in bug 1578381. A preference that is currently controlled by an extension is getting changed directly rather than (or in addition to) using ExtensionSettingsStore.

We're adding search settings to the setting store[1][2], but it is not being updated when the search service is removing the extension (or search provider, not sure what it's doing). Whereever that removal is happening, we should make sure that ExtensionSettingsStore.removeSetting is also called.

Currently we either:

• ignore the engine - if it is in the ignore list when it is being added
• remove the engine - if the ignore list is updated

In the ignore when added case, we could possibly make addEnginesFromExtension aware of the fact the engine hasn't been added... at the moment it looks like the function returns the new engines, but they might not have been added.

For the update case, we should probably tell the settings store somehow.

Comment 3

[Mark Banner (:standard8)]

The message "An extension, Ecosia - The search engine that plants trees, has set your default search engine." has now been removed from the UI and is never displayed, hence closing as WFM.