Gecko-side strings (Strings.browser.GetStringFromName) aren't updated after a locale change

VERIFIED FIXED in Firefox 56

Status

()

Firefox for Android
Locale switching and selection
--
major
VERIFIED FIXED
6 months ago
5 months ago

People

(Reporter: Virtual, Assigned: gandalf)

Tracking

(Blocks: 1 bug, {nightly-community, regression})

55 Branch
Firefox 57
All
Android
nightly-community, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(fennec+, firefox-esr52 unaffected, firefox55 wontfix, firefox56 verified, firefox57 verified)

Details

(Whiteboard: [fixed by patch from bug #1378501])

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment)

STR:
1. Start Mozilla Firefox Mobile
2. Press "Hamburger" button
3. Press "Settings" item in Hamburger menu
4. Press "Privacy" item in Settings menu
5. Enable "Clear private data on exit"
6. and select everything in next menu, except "Downloads" item
7. Press "SET"
8. Pres  <- ("Back") button to go to Settings menu
9. Press "Genera" item in Settings menu
10. Press "Language" item in General menu
11. Select "English (United States)" language
12. Pres  <- ("Back") button to go to General menu
13. Pres  <- ("Back") button to go to Settings menu
14. Pres  <- ("Back") button to go to Firefox tabs
15. Press "Hamburger" button
16. Press "Quit" item in hamburger menu
and see that "Clearing private data..." information is showing as localized one "Czyszczenie prywatnych danych...".
Changing Android language from Polish to English (Unite States) doesn't change anything.

Mozilla Firefox Mobile 55.0 on Android 6.0.1
Has STR: --- → yes
QA Contact: Virtual

Comment 1

6 months ago
It looks like Strings.browser.GetStringFromName continues returning whatever locale was initially selected during the browsing session, at least for things handled by our JS chrome code, because this also affects our context menus, the various messages when opening/closing tabs, etc. Things like about:addons, about:firefox, our error messages on the other hand correct themselves after a reload (maybe that's a clue - we don't "reload" our UI code after a locale change), although interestingly enough the preinstalled H264 codec in about:addons continues being localised in whatever locale was initially active even after a reload of about:addons.
Hardware: ARM → All
Summary: "Clearing private data..." is showing as localized one instead of in language selected in Mozilla Firefox Mobile settings → Gecko-side strings (Strings.browser.GetStringFromName) aren't updated after a locale change

Comment 2

6 months ago
Hi Jan
Nice catch! Do you think we should restart the app when there's a configuration change? 


Hi snorp
Is there a way for Gecko to re-load the locale string?
Flags: needinfo?(snorp)
Flags: needinfo?(jh+bugzilla)

Comment 3

6 months ago
No, we should fix Strings.browser.GetStringFromName to work properly. I haven't looked how far back this problem goes, but maybe it's still some fallout from the relatively recent-ish locale system changes that also caused some other bugs.
Flags: needinfo?(jh+bugzilla) → needinfo?(gandalf)
Richard may have some info here too
tracking-fennec: ? → +
status-firefox55: --- → fix-optional
status-firefox56: --- → affected
status-firefox57: --- → affected
Flags: needinfo?(snorp) → needinfo?(rnewman)
(In reply to Jan Henning [:JanH] from comment #3)
> No, we should fix Strings.browser.GetStringFromName to work properly. I
> haven't looked how far back this problem goes, but maybe it's still some
> fallout from the relatively recent-ish locale system changes that also
> caused some other bugs.

I don't know if anyone ever tested locale switching with the clear private data on exit code flow.

browser.js uses thunks to accommodate dynamic locale changes:

  initContextMenu: function () {
    // We pass a thunk in place of a raw label string. This allows the
    // context menu to automatically accommodate locale changes without
    // having to be rebuilt.
    let stringGetter = name => () => Strings.browser.GetStringFromName(name);

    // TODO: These should eventually move into more appropriate classes
    NativeWindow.contextmenus.add(stringGetter("contextmenu.openInNewTab"),

and that _was_ tested: our context menus, last I was involved with Fennec, correctly reflected changes in in-app locale.

If they're no longer doing so, then it seems that somebody regressed GSFN, perhaps in a bug like Bug 1351873. Gandalf is the right person to ask.
Flags: needinfo?(rnewman)
(Assignee)

Comment 6

6 months ago
Yep, I'll be debugging this tomorrow.
See Also: → bug 1378501
(Assignee)

Updated

6 months ago
Assignee: nobody → gandalf
Status: NEW → ASSIGNED
Flags: needinfo?(gandalf)
Comment hidden (mozreview-request)
(Assignee)

Comment 8

6 months ago
I regressed it in bug 1346617. Bringing back the flush fixes this issue.
Blocks: 1346617
Has Regression Range: --- → yes
status-firefox-esr52: --- → unaffected
Keywords: regression
I have the one-line fix for this in my patch for Bug 1378501. Waiting on hg account reactivation so I can push.
See Also: → bug 1398209
Fixed in Bug 1378501.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1378501
Blocks: 1398209
Status: RESOLVED → VERIFIED
status-firefox55: fix-optional → wontfix
status-firefox56: affected → verified
status-firefox57: affected → verified
Resolution: DUPLICATE → FIXED
See Also: bug 1378501, bug 1398209
Whiteboard: [fixed by patch from bug #1378501]
Target Milestone: --- → Firefox 57
Attachment #8905678 - Flags: review?(rnewman)
You need to log in before you can comment on or make changes to this bug.