Open Bug 1586657 Opened 5 years ago Updated 2 years ago

Dialog for spoofing the locale in resist-fingerprinting-mode contains non-localized buttons

Categories

(Core :: Internationalization, defect, P3)

Product:
Core
Component:
Internationalization
Version:
68 Branch
Type:
defect

Tracking

()

People

(Reporter: gk, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression, Whiteboard: [tor 31980])

In bug 1039069 a dialog got added that allows the user to spoof the locale, which web content/servers are seeing, to en-US if non-en-US builds are used and resist fingerprinting mode is enabled.

That works and the dialog looks properly localized in the old ESR (ESR 60 that is), but in the new ESR (ESR 68) the dialog buttons are shown in en-US while the remaining text is properly localized.

Two crucial pieces the reproduce this bug:

  1. It only happens during first start
  2. It only happens if one gets a localized build by using the language packs. The bundles as Mozilla ships them are not affected.

I suspect there is a change that lead to the lang pack .xpis being not early enough available to be used for the dialog button localization on first start.

(Localization might be the wrong component to file this bug in. Sorry, if so but it's hard to find the right one as the cause of the bug is not tracked down yet)

Moving over to Intl, where most of these bugs are.

Component: Localization → Internationalization

A few days ago Dave landed a patch that might be a fix for this bug (bug 1586216). Reporter, can you try to reproduce this in the latest Nightly? Thank you!

Flags: needinfo?(gk)

I backported the patch to esr68 as I thought to test it in the environment we actually ship to users (the patch applied cleanly) but the problem still exists.

Let me know if you think I should really try the nightly instead. That said, I might find time to bisect my way to the bad commit next week if that would be helpful.

Flags: needinfo?(gk)
Priority: -- → P3

(In reply to Georg Koppen from comment #3)

I backported the patch to esr68 as I thought to test it in the environment we actually ship to users (the patch applied cleanly) but the problem still exists.

Let me know if you think I should really try the nightly instead. That said, I might find time to bisect my way to the bad commit next week if that would be helpful.

Time flies and I had no time to bisect but the problem still exists with esr78.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.