1520446 - Page action for screenshots is not updated when switching back to language of the build

Status: RESOLVED FIXED

(WebExtensions :: General, defect, P1)

Description

[Francesco Lodolo [:flod]]

I'm using an Italian Build of 65 beta (65.0b11 (64 bit)).

Via Preferences I search for new languages, install French and switch to it.
In the page actions menu, the "Screenshot" item is correctly localized in French.

If I switch back the language of the build (Italian in my case), that menu remains in French.

Comment 1

[Ian Bicking (:ianbicking)]

We set the title of the page action via manifest.json, like:

  "page_action": {
    "browser_style": true,
    "default_icon" : {
      "32": "icons/icon-v2.svg"
    },
    "default_title": "__MSG_contextMenuLabel__",
    "show_matches": ["<all_urls>"],
    "pinned": false
  },

The localization itself is handled in Firefox, so I think this is a WebExtension bug.

Comment 2

[emanuela [ux]]

Attachment: Screen Shot 2019-02-01 at 14.05.05.png

I have a similar issue with the themes name.

Comment 3

[Francesco Lodolo [:flod]]

(In reply to emanuela [ux] from comment #2)

Created attachment 9040689 [details]
Screen Shot 2019-02-01 at 14.05.05.png

I have a similar issue with the themes name.

I suggested Emanuela to comment here, in case the cause might be the same. Happy to split into a different bug if that turns out to not be the case.

Comment 4

[David Durst [:ddurst]]

Is this not only at runtime? If you restart this persists?

Comment 5

[Francesco Lodolo [:flod]]

(In reply to David Durst [:ddurst] from comment #4)

Is this not only at runtime? If you restart this persists?

No clue how, but it persists after a restart (even a complete shutdown+start).

Comment 6

[David Durst [:ddurst]]

Attachment: page actions

Comment 7

[David Durst [:ddurst]]

Attachment: aboutaddons themes

Comment 8

[David Durst [:ddurst]]

Attachment: aboutaddons plugins

Comment 9

[David Durst [:ddurst]]

Attachment: firefox menu

Comment 10

[David Durst [:ddurst]]

So, STR:

1. In Release or Beta, add another language under "Choose the languages used to display menus, messages, and notifications from Firefox."
2. Select the new language, then click Apply and Restart.
3. Once restarted, switch back to the original language, then click Apply and Restart.

Expected results:

• Upon restart, all things are in the original language

Actual results:

• Upon restart:
  a. the screenshot page action (and only that one) is still in the new language
  b. in about:addons, the active theme (and only that one) is still in the new language
  c. in about:addons, widevine and OpenH264 plugin cards are still in the new language
  d. the Firefox menu options are still in the new language
• Upon subsequent restart (with no additional language change), d. changes to the original language; a-c do not.

Comment 11

[Francesco Lodolo [:flod]]

(In reply to David Durst [:ddurst] from comment #9)

Created attachment 9041818 [details]
firefox menu

This one is bug 1505775 (it seems unrelated to add-ons)

Comment 12

[Julien Cristau [:jcristau] (back April 22)]

Rob, this is P1 and untouched in quite a while, is this still being worked on?

Comment 13

[Markus Keller]

Some of these "mixed language" issues also occur without third-party extensions. Bug 1564998 mentions a temporary solution: Exit Firefox, run "firefox.exe -purgecaches".

Comment 14

[Rob Wu [:robwu]]

Was still able reproduce in 68.0.1, but not on Nightly 71.0a1 buildID 20190908214439.

This bug happens when the langpack is loaded before the built-in language is registered.

• Originally, the [L10nRegistry.registerSource was called at "final-ui-startup
• In bug 1555662, the registerSource call was moved to when L10nRegistry.jsm is loaded) (loaded at "app-startup").
• In bug 1558306, the JSM load was moved to "ipc:first-content-process-created".

From the langpack/extension's point of view, the exact entry point of of the L10nRegistry.jsm does not matter, because the langpack registration happens via a call to L10nRegistry.registerSource, and upon accessing that module, the built-in language are registered.

Thus, fixed by bug 1555662.

---

How I figured this out:

I added some logging, and managed to capture why this bug occurs. Replace the manifestCacheKey getter with the following:

  get manifestCacheKey() {
    let retval = [this.id, this.version, Services.locale.appLocaleAsLangTag];
    dump(`manifestCacheKey=${uneval(retval)} ${new Error().stack}\n`);
    if (!Math.x) { Math.x = 1; // nothing special about "Math", but I want to run this code once.
      Services.obs.addObserver(() => dump(`LOCALECHANGED ${Services.locale.appLocaleAsLangTag} ${new Error().stack}\n`)}, "intl:app-locales-changed"));
    }
    return retval;
  }

... and then run the following STR:

1. Start Firefox (default language is en-US).
2. Visit about:config and set browser.dom.window.dump.enabled to true.
3. Visit about:preferences and install a different langpack (e.g. Dutch / nl).
4. Confirm the restart.
5. At about:preferences, set the language to the default language (e.g. en-US).
6. Confirm the restart.
7. Look at the console (stdout) for the messages that were generated at startup.

Result (Firefox 68.0.1 buildID 20190717172542, patched omni.ja to include the above logging snippet):

manifestCacheKey=["[e-mail]", "1.1", "en-US"] get manifestCacheKey@resource://gre/modules/Extension.jsm:1597:43
(... stack trace omitted because it is similar as the following ones ...)

manifestCacheKey=["[e-mail]", "1.0", "en-US"] get manifestCacheKey@resource://gre/modules/Extension.jsm:1597:43

manifestCacheKey=["[e-mail]", "1.0", "en-US"] get manifestCacheKey@resource://gre/modules/Extension.jsm:1597:43

manifestCacheKey=["[e-mail]", "1.0", "en-US"] get manifestCacheKey@resource://gre/modules/Extension.jsm:1597:43

manifestCacheKey=["[e-mail]", "1.0", "en-US"] get manifestCacheKey@resource://gre/modules/Extension.jsm:1597:43

manifestCacheKey=["[e-mail]", "1.0", "en-US"] get manifestCacheKey@resource://gre/modules/Extension.jsm:1597:43

manifestCacheKey=["[e-mail]", "1.0", "en-US"] get manifestCacheKey@resource://gre/modules/Extension.jsm:1597:43

manifestCacheKey=["[e-mail]", "3.0", "en-US"] get manifestCacheKey@resource://gre/modules/Extension.jsm:1597:43

manifestCacheKey=["[e-mail]", "1.0", "en-US"] get manifestCacheKey@resource://gre/modules/Extension.jsm:1597:43
parseManifest@resource://gre/modules/Extension.jsm:1628:5
loadManifest@resource://gre/modules/Extension.jsm:899:12
loadManifest@resource://gre/modules/Extension.jsm:1640:32
startup@resource://gre/modules/Extension.jsm:1914:18
startup@resource://gre/modules/Extension.jsm:1313:27
callBootstrapMethod@resource://gre/modules/addons/XPIProvider.jsm:1742:33
startup@resource://gre/modules/addons/XPIProvider.jsm:1841:32
startup@resource://gre/modules/addons/XPIProvider.jsm:2325:39
callProvider@resource://gre/modules/AddonManager.jsm:193:31
_startProvider@resource://gre/modules/AddonManager.jsm:569:5
startup@resource://gre/modules/AddonManager.jsm:725:14
startup@resource://gre/modules/AddonManager.jsm:2797:26
observe@resource://gre/modules/addonManager.js:65:29

LOCALECHANGED nl get manifestCacheKey/<@resource://gre/modules/Extension.jsm:1601:1
registerSource@resource://gre/modules/L10nRegistry.jsm:192:47
startup@resource://gre/modules/Extension.jsm:2196:20
startup@resource://gre/modules/Extension.jsm:1361:26
callBootstrapMethod@resource://gre/modules/addons/XPIProvider.jsm:1742:33
startup@resource://gre/modules/addons/XPIProvider.jsm:1841:32
startup@resource://gre/modules/addons/XPIProvider.jsm:2325:39
callProvider@resource://gre/modules/AddonManager.jsm:193:31
_startProvider@resource://gre/modules/AddonManager.jsm:569:5
startup@resource://gre/modules/AddonManager.jsm:725:14
startup@resource://gre/modules/AddonManager.jsm:2797:26
observe@resource://gre/modules/addonManager.js:65:29

manifestCacheKey=["[e-mail]", "1.0", "nl"] get manifestCacheKey@resource://gre/modules/Extension.jsm:1597:43
( ... stack trace omited because it's similar to other search add-ons ... )

manifestCacheKey=["[e-mail]", "39.0.0", "nl"] get manifestCacheKey@resource://gre/modules/Extension.jsm:1597:43
( ... stack trace similar as before, note that this is the extension that the bug is about ... )

manifestCacheKey=["[e-mail]", "1.0", "nl"] get manifestCacheKey@resource://gre/modules/Extension.jsm:1597:43

manifestCacheKey=["[e-mail]", "4.3.2", "nl"] get manifestCacheKey@resource://gre/modules/Extension.jsm:1597:43

manifestCacheKey=["[e-mail]", "1.0", "nl"] get manifestCacheKey@resource://gre/modules/Extension.jsm:1597:43

LOCALECHANGED en-US get manifestCacheKey/<@resource://gre/modules/Extension.jsm:1601:1
registerSource@resource://gre/modules/L10nRegistry.jsm:192:47
BG__beforeUIStartup@resource:///modules/BrowserGlue.jsm:1062:18
BG_observe@resource:///modules/BrowserGlue.jsm:763:14

( ... wait a while, meanwhile the webcompat add-on updated by coincidence ... )

manifestCacheKey=["[e-mail]", "5.0.2", "en-US"] get manifestCacheKey@resource://gre/modules/Extension.jsm:1597:43
parseManifest@resource://gre/modules/Extension.jsm:1628:5
loadManifest@resource://gre/modules/Extension.jsm:899:12
loadManifest@resource://gre/modules/Extension.jsm:1640:32
startup@resource://gre/modules/Extension.jsm:1914:18
startup@resource://gre/modules/Extension.jsm:1313:27
callBootstrapMethod@resource://gre/modules/addons/XPIProvider.jsm:1742:33
startup@resource://gre/modules/addons/XPIProvider.jsm:1841:32
_install@resource://gre/modules/addons/XPIProvider.jsm:1914:18

Now, when I look at the current source, there is no L10nRegistry.registerSource in BG__beforeUIStartup any more. It appears to have been moved to the "app-startup" notification in bug 1555662, and then moved to "ipc:first-content-process-created" in bug 1558306.