1781768 - Search engines installed via WebExtensions do not update the search engine name when live language switching

Status: VERIFIED FIXED

(Firefox :: Search, defect, P2)

Description

[Mark Banner (:standard8)]

Firefox 100 introduced live language switching. Soon after that, there is an increase in our telemetry for when the installed search engine name differs from that of the associated WebExtension.

This increase appears to be mainly associated with the Startpage add-on.

Investigating in more detail shows that the add-on defines a different search engine name for each language, it also uses a different search url for each language.

When switching, we are not updating neither the name, nor the search url - this is a case we're missing, since we only update/change things for application provided WebExtensions, not user installed ones.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:standard8, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 2

[Mark Banner (:standard8)]

I started looking at this, and it is a bit more complicated than I realised. There's a few issues:

SearchService.#getManifestForLocale assumes that it can use the extension's default locale if one is specified. The problem here is that the extension default locale has been specified by the extension (typically 'en') and is constant - this is fine for application provided engines, but not for third-party add-on engines.

This also points to another bug, that when we install a third party add-on with localised names for search engines, we always the name from the default locale specified by that engine. Hence we should modify #getManifestForLocale to work with third-party engines as well.

However that is not enough by itself because when the search service received the notification about a locale change we are not guaranteed that the add-on manager will have updated the extension's extension.manifest to be the new locale.

Although the add-on manage does update itself, as far as I can tell, ext-chrome-settings-overrides.js receives no notifications for neither onManifestEntry nor onUpdate.

Shane/Rob, is there an existing notification that we could use for when the manifest changes due to a locale change, or is this something that needs to be added to the add-on manager?

Comment 3

[Rob Wu [:robwu]]

Localized manifests are not refreshed until the extension restarts. There is no mechanism in the extension API to refresh the components of the extension itself. The contents of the Addon Manager (about:addons) does immediately reflect the actual locale because the strings there are directly read from the add-ons database, which is independent of the running instance of Extension in memory.

When the extension starts up, any previously cached manifest data is used. This (localized) manifest data is keyed by the locale in use. As part of manifest loading, the available locale is negotiated in extension.initLocale, using the UI language if available in the set of locales, with a fallback to the default_locale value in the manifest.json file.
The final value is stored on the in-memory running extension instance, at (extension).localeData.selectedLocale: https://searchfox.org/mozilla-central/rev/9f2f65d1663b4db2907749e5bbbfe6a81ac43bca/toolkit/components/extensions/Extension.jsm#1844

If you have reason to believe that the language after extension startup is inaccurate, then you could check whether the repeating the logic of initLocale matches with the value of extension.localeData.selectedLocale, and if it differs, try to get a different manifest. If they are same, you can take the cheap/fast path by re-using the already-parsed manifest data.

The previously linked logic in SearchService.sys.mjs hard-codes the use of "default_locale" as "DEFAULT_TAG". I guess that you should be using Services.locale.appLocaleAsBCP47 instead, with a fallback to default_locale otherwise, i.e. logic similar to the initLocale method linked before.

Comment 4

[Mark Banner (:standard8)]

Thanks, I think the suggestions there are the right thing to do.

Comment 5

[Mark Banner (:standard8)]

Attachment: Bug 1781768 - When live language switching ensure that search engines installed via add-ons also update. r?#search-reviewers!

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f00c3546b0a5
When live language switching ensure that search engines installed via add-ons also update. r=search-reviewers,settings-reviewers,mconley,daleharvey

Comment 7

[Noemi Erli[:noemi_erli]]

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

Comment 8

[Cristian Baica [:cbaica], Release Desktop QA]

Tested using the latest Fx 111.0a1 on Window 10 and Ubuntu 22.04, with Startpage addon that can be found here.

Testing was done for the following locales: da, de, en, es, fr, nb, nl, nn, pl, pt_BR, pt_PT, sv that are supported by the addon. On live language switch the search engine name was changed to match the locale name.

Other interactions tested:

• interaction with other addon search engines
• interaction with locales not supported by the addon

No issues encountered.