Closed Bug 1564998 Opened 3 months ago Closed 2 months ago

Half of interface in different language

Categories

(Toolkit :: Add-ons Manager, defect, P2)

68 Branch
defect

Tracking

()

RESOLVED DUPLICATE of bug 1566084
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 - wontfix
firefox68 + wontfix
firefox69 + wontfix
firefox70 + wontfix

People

(Reporter: Lalabuy9948, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: regression)

Attachments

(2 files)

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

Steps to reproduce:

Open firefox after 68 update

Actual results:

Half interface in different language which is not the same as in preferences

Expected results:

I would expect English everywhere...

Not a security bug that needs to stay hidden.

Can you provide a screenshot that shows the other language(s)? And can you attach the raw data from about:support (help > troubleshooting information > copy raw data to clipboard, then paste in the box at https://bugzilla.mozilla.org/attachment.cgi?bugid=1564998&action=enter ) ? Thank you!

Group: firefox-core-security
Flags: needinfo?(Lalabuy9948)

[Tracking Requested - why for this release]:

Given that updates are (I expect?) still throttled, that seems like a lot of sumo/reddit traffic for something like this, with no clear user remedy. The i18n/l10n section copy-pasted into https://support.mozilla.org/en-US/questions/1264272 also suggests there's supposed to only be en-US and there's no indication of where the estonian is even coming from. It's additionally confusing that the content in the screenshot in that support thread that's in estonian is in the menu, and that uses dtds, so it's not fluent being confused here, it's something else.

I wonder if this is because we stopped flushing chrome caches when installing/uninstalling add-ons (like, say, language packs) but that doesn't feel like a complete explanation if the user was using English before the update, in addition to the fact that we should still be flushing caches for updates themselves anyway, and the fact that that change was made in 67 so I'd have expected reports before now if it were an issue. (bug 1445739, fwiw).

Axel/:flod/:stas/:gandalf, ideas appreciated...

I assume your build is originally Estonian, and you installed a language pack for English?

Can you try following these instructions, and use firefox.exe -purgecaches instead of the command indicated there?

If that works, it's bug 1520446 :-\

an affected user at https://support.mozilla.org/en-US/questions/1264272#answer-1236634 reported back that running firefox with the -purgecaches command did indeed solve the issue for him.

Another one. At this point, I assume we changed something, because that's not a normal frequency
https://blog.mozilla.org/l10n/2019/04/02/changing-the-language-of-firefox-directly-from-the-browser/#comment-25867

Are these reports all on mac?

the reports i've seen after the 68 update and where users specified their OS were all windows.

Pinging harder for comment 3, can you think of changes in 68 that could affect this?

Flags: needinfo?(stas)
Flags: needinfo?(gandalf)

I can only confidently talk about the core of Fluent, which last changed in mozilla-central in the end of March. That would still count for 68, but I can't think of any changes that would cause such behavior. It also looks like this affects strings which are still in DTDs. Sorry that I can't help more.

Flags: needinfo?(stas)

I wonder if bug 1556832 changed something around purgecaches being kicked on software update.

Tentatively moving it over to startup, and Mossop, can you check if this could be a regression of bug 1556832?

Clearing other needinfos for now.

Component: Internationalization → Startup and Profile System
Flags: needinfo?(gandalf)
Flags: needinfo?(dtownsend)
Flags: needinfo?(Lalabuy9948)
Product: Core → Toolkit

As far as I can tell we are still flushing caches as normal. What does this look like when it happens? Which parts of the UI are affected?

Flags: needinfo?(dtownsend)

Here's an example from SUMO
https://user-media-prod-cdn.itsre-sumo.mozilla.net/uploads/images/2019-07-10-00-41-44-8a3078.png

The problem is if the language pack is re-enabled after a software update (bug 1566084). Do we purge caches in that case?

So the strings that seem broken will mostly come from dtds, which means we would need to flush the startup cache to get them to be reloaded (also you'd need to reopen the window at the least). So if the locale pack gets updated when the firefox version doesn't change then the add-ons manager should explicitely flush the startup cache when installed. I can't see it doing that and looks like we explicitely stopped it from doing that: bug 1445739. I suspect that that is the issue, but that was fixed in 67 so not sure why this is mainly affecting 68.

Component: Startup and Profile System → Add-ons Manager

I tried to reproduce, but I only get to an half translated browser until I restart.

  1. Installed 67.0.4 French build from
    http://ftp.mozilla.org/pub/firefox/releases/67.0.4/mac/fr/

Started build offline, created a new profile.

  1. Installed the Chinese language pack from FTP (still offline). Picked Chinese, since it's very easy to spot the wrong language.
    http://ftp.mozilla.org/pub/firefox/releases/67.0.4/mac/xpi/zh-TW.xpi

  2. Go in Preferences, switch to Chinese. Restart the browser.

  3. At this point the browser is online and fully localized in Chinese. Search for Firefox updates to 68.0 and restart.

  4. The browser restarts in French, with a warning that the language pack is not compatible.

  5. Search for add-ons updates. It should find an update for Chinese. At this point, some of the windows will have a mix of languages.

In my case, after a restart the browser is fully localized in Chinese. Not sure if on Windows that persists after the restart.

After the language pack is updated and re-enabled, the UI is a mix of languages.

I would expect that the strings that don't get updated until you restart are coming from dtd/properties. We don't currently update these dynamically (part of the desire to switch to fluent). So what you're seeing is basically what I'd expect to see when things are working as correctly as they can be right now. That does suggest that something is flushing the startup cache though.

Do we need to bring back the cache flush from bug 1445739, at least when langpacks change?

(In reply to Julien Cristau [:jcristau] from comment #18)

Do we need to bring back the cache flush from bug 1445739, at least when langpacks change?

I'm not opposed to doing this but based on comment #16 / comment #17 I think we still don't really understand what's going on here, in that we can't reproduce the problem as filed, nor do we understand the root cause of why it started appearing in 68.

We could still try to do the flushing as wallpaper fix to attempt to get users out of limbo here. Also, even if we added flushing for langpack updates, that wouldn't solve the issue for that running Firefox (ie it'd require a restart) and we have no upliftable way of prompting the user to restart (maybe apart from force-opening about:restartrequired or something? Which uses fluent so won't need the restart to show in the "right" language, so that's good?) - plus, if we ever update langpacks out of band (ie more than once per a given release) then we might prompt too often; it might be tricky to know exactly when a cache flush and restart are required, and when they are not.

Feels like the decision / next step is up to some intersection of add-on manager and l10n folks. Andrew/Axel, thoughts on how to proceed?

Flags: needinfo?(l10n)
Flags: needinfo?(aswan)

I speculate this bug is fall-out from not updating the langpack as part of the update process, which is bug 1566084.

I'm also concerned that we don't know how the exact symptoms here can be reproduced, but if we could just not update the langpack(s) late, we'd not face this area of problems?

Flags: needinfo?(l10n)

I don't have much to add to what Gijs says, I also don't feel really comfortable with short-term fixes when we don't understand the underlying problem.
Note that in one of the sumo threads a user reported that switching to another language and then switching back solved the problem. I would guess that's because changing languages triggers:
https://searchfox.org/mozilla-central/rev/4fbcfe6fecf75d7b828fbebda79a31385f7eab5f/chrome/nsChromeRegistryChrome.cpp#201-204

The whole experience around browser updates for users with language packs is pretty poor and has been for some time, I'm also surprised that it wasn't reported earlier than bug 1566084. Presumably fixing bug 1566084 would (eventually) take care of users affected by this bug.

But that fix presumably wouldn't go out until 70 at the earliest and meanwhile we have users affected. In the short term, I could write a patch to flush the startup cache when a langpack is updated but we can't really test it if we can't reliably reproduce what's being reported by our users.

Krupa, are you the right QA contact for this bug? I'm wondering if we could get some help trying to get concrete STR here?

Flags: needinfo?(aswan) → needinfo?(kraj)

(In reply to Axel Hecht [:Pike] from comment #20)

I speculate this bug is fall-out from not updating the langpack as part of the update process, which is bug 1566084.

Worth noting that the only way we might resolve that issue would be to update the langpack as part of the automated update process, which wouldn't cover a number of users.

I'm also concerned that we don't know how the exact symptoms here can be reproduced, but if we could just not update the langpack(s) late, we'd not face this area of problems?

I don't think we know that without knowing what is actually causing this. Depending on the cause this may affect langpack updates when Firefox isn't updated too.

We really need solid steps to reproduce here I think.

(In reply to Francesco Lodolo [:flod] from comment #15)

In my case, after a restart the browser is fully localized in Chinese. Not sure if on Windows that persists after the restart.

I wonder if there would be any difference if you were to restart Firefox a couple of times before manually updating the Chinese pack.

(In reply to Axel Hecht [:Pike] from comment #20)

I speculate this bug is fall-out from not updating the langpack as part of the update process, which is bug 1566084.

That didn't change in 68 though, did it?

Either way, I concur with Dave and Andrew that we need solid STR and a better understanding of what's broken here.

(In reply to Dave Townsend [:mossop] (he/him) from comment #22)

I wonder if there would be any difference if you were to restart Firefox a couple of times before manually updating the Chinese pack.

Tried that, also tried to open a bunch of menus after updating the language pack and before restarting (e.g. hamburger menu, customize window), but after a restart the browser is all in Chinese. I also realize that the screenshot from the original reporter, although not useful, is from macOS.

Windows 10 Pro, is behaving exactly like my Mac in comment 15. I even tried to let the browser open, and allow the add-on to update on its own, but I got the same result (browser was fully localized after restarting).

Note: If we want to start purging the startup cache when langpacks are updated again, it needs to happen in the langpack code, not as another special case in the XPIProvider code.

(In reply to Kris Maglione [:kmag] from comment #26)

Note: If we want to start purging the startup cache when langpacks are updated again, it needs to happen in the langpack code, not as another special case in the XPIProvider code.

Concur. And even better than startup() would be to add an update() method to the langpack bootstrap class. Especially if we are able to address bug 1566084, update() will be the reliable way to know when the langpack has changed.

I have managed to reproduce the issue with the steps provided in Comment 15 on the following versions of Firefox with RO locale on Windows 10 Pro 64-bit and macOS High Sierra 10.13.6:

The corresponding Chinese (zh-CN) language pack has been used to reproduce the issue, since it is easier to distinguish the changes occurring in the browser upon installing it, as stated in Comment 15.

The following were observed:

After step 5 some of the pages are a mix of the RO and CH languages. Proceeding with step 6 and updating the language pack will cause most of the windows to revert to the initial language (with CH still present in the Recommendations sections of the both the Recommendations and Extensions tabs). Refreshing the page will cause about:addons to become mixed again, to a higher degree.

Restarting the browser will fully localize in the installed language pack (CH).

After installing the language pack, a new tab appears in abbout:addons (languages tab, where the installed language pack can be seen). Disabling the language pack from there will cause the pages to jumble up again. Restarting will properly localize in RO.

After restart, enabling the language pack again from the languages tab will cause the issue once more which is solved after another restart.

In conclusion, I did not manage to make the issue persist after a browser restart.

Note:

For ESR and Nightly, which do not have an option to change the browser language, the corresponding language pack has been installed and the language has been changed via the ‘ intl.locale.requested’ pref, set to ‘zh-CN, zh’ as the used language pack was the Chinese one.

I’ve also tried a similar method of reproducing, more similar to the scenario of the reporter, i.e. having FX67 RO locale installed, going to about:preferences and changing to an alternative language (en-US), restarting the browser (which caused the update to the latest version) and then noticing the mix of languages in about:addons.

See Also: → 1567486
Duplicate of this bug: 1567796
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(kraj)

Jim, can you help us find someone to make progress on this? Thanks.

Flags: needinfo?(jmathies)

This has to do with language pack updating. Not a small project.

Depends on: 1566084
Flags: needinfo?(jmathies)
Priority: -- → P3

Changing the priority to p1 as the bug is tracked by a release manager for the current release.
See What Do You Triage for more information

Priority: P3 → P1
See Also: → 1569653

Doesn't sound like there's any realistic chance of fixing this in the 68/69 timeframe. Not sure about 70+ but this feels like a bug we need to keep on the radar in the mean time.

Priority: P1 → P2
Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1566084

I had this problem in ff 68 and it solved with firefox.exe -purgecaches But now, with auto-updated to ff 69 (User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0) it reproduced again and fix didn't work: popup menu, about:addons displayed in Russian, about:preferences page, About dialog in English.

Oh, I found how to fix it:

  • go to the about:addons - Languages,
  • manually update Language pack (even if you have option set to Auto-update)
  • close ff and run command firefox.exe -purgecaches

I wonder why the Language pack did not update automatically with ff update?

http://prntscr.com/p1frlm

Duplicate of this bug: 1579396

(In reply to starmen from comment #42)

Oh, I found how to fix it:

  • go to the about:addons - Languages,
  • manually update Language pack (even if you have option set to Auto-update)
  • close ff and run command firefox.exe -purgecaches

I wonder why the Language pack did not update automatically with ff update?

http://prntscr.com/p1frlm

Where should i run this command?

In the Windows command prompt from folder where firefox installed.

Press hotkey Win + R, type cmd and press Enter.
Then navigate to the folder where firefox installed: type cd /D "C:/Program Files/Mozilla Firefox" (default ff x64 location).

You need to log in before you can comment on or make changes to this bug.