Changes to `intl.accept.languages` get overwritten after restart
After mentioning an issue with localized content on the blog ( https://blog.torproject.org/comment/269161#comment-269161) I investigated a bit and it seems changes to intl.accept_languages get overwritten after restarting Tor Browser by our custom values. Other preferences might be affected as well.
This is at least affecting our fix for #21999 (moved).
Activity
There is nothing obviously wrong with the logic. The same works in Tor Browser 6.5.x but in Tor Browser 7 doing
m_tb_prefs.clearUserPref("intl.accept_languages");does not give us back the
intl.accept_languagesvalue which is inchrome://global/locale/intl.properties(in case one has a non-en-US bundle) buten-US, en. It's not clear yet where that new value is coming from.-
Replying to mcs:
How can I reproduce this bug? I tried toggling
extensions.torbutton.spoof_englishwithin 7.0.1 on OSX, andintl.accept_languageswas correctly updated.It gets correctly updated, yes, but after a restart that is gone again which should not happen and is not happening in the 6.5.x series. I tested that with Arthur's patch in #21999 (moved) but it is not related to it.
So far I cannot reproduce this problem when testing on OSX without the patch for #21999 (moved). Here is what I did:
- Opened a clean copy of the es-ES variant of Tor Browser 7.0.1 (no preexisting TorBrowser-Data directory).
- Clicked
Conectarduring startup. - Opened about:config and noted that the value for
intl.accept_languageswasen-US, enas expected. - Used about:config to toggle
extensions.torbutton.spoof_englishtofalseand noted that theintl.accept_languagesvalue had been changed toes-ES, es, en-US, en(the default value). - Restarted the browser and checked the
intl.accept_languagesone more time. The value was stilles-ES, es, en-US, en.
-
Replying to mcs:
So far I cannot reproduce this problem when testing on OSX without the patch for #21999 (moved). Here is what I did:
- Opened a clean copy of the es-ES variant of Tor Browser 7.0.1 (no preexisting TorBrowser-Data directory).
- Clicked
Conectarduring startup. - Opened about:config and noted that the value for
intl.accept_languageswasen-US, enas expected. - Used about:config to toggle
extensions.torbutton.spoof_englishtofalseand noted that theintl.accept_languagesvalue had been changed toes-ES, es, en-US, en(the default value). - Restarted the browser and checked the
intl.accept_languagesone more time. The value was stilles-ES, es, en-US, en.
I followed those five steps and I get
en-US, enas result. Could you test on a Linux box (I did that)? Maybe that's the difference (although this would be even weirder)... -
Kathy and I can reproduce the problem on Linux (but still not on OSX). The incorrect value definitely comes from the en-US file (toolkit/locales/en-US/chrome/global/intl.properties). We confirmed that by changing the value there to
en-US, en, frand seeing that when this bug occurs the "default" value is indeeden-US, en, fr. Your comment:7 experiment is interesting. From the URL bar, you saw the correct data but somehow the prefs system seems to be ignoring the language pack and consulting the en-US intl.properties file. The mystery is why. Thegeneral.useragent.localepref does not seem to be suffer from the same bug even though its value should be determined by the same mechanism. Others enjoy it too https://bugzilla.mozilla.org/show_bug.cgi?id=654099
-
Replying to cypherpunks:
Others enjoy it too https://bugzilla.mozilla.org/show_bug.cgi?id=654099
But isn't that bug about the literal value
chrome://global/locale/intl.propertiesshowing up (as a string)? I think this ticket covers a different but possibly related problem. -
Hm, so, bisecting gives me https://bugzilla.mozilla.org/show_bug.cgi?id=1295608 as the culprit. It has l10n related changes but they should be only relevant to the devtools...
-
An update on that one: It seems there are different issues here at work. The one is that the
intl.accept_languagespref is not correctly updated/shown and the other one is that the wrong header values are sent.Surprisingly, those issues don't belong together. I.e. the first one is fixed with Tor Browser 7.5a8, more exactly with the TorLauncher 0.2.14.1 update. The other one is unaffected by it. https://bugzilla.mozilla.org/show_bug.cgi?id=1005640 fixed a pretty similar problem for Firefox (it landed in version 55). I guess a next step would be to backport that patch and look whether we are good on ESR 52 as well.
Trac:
Cc: N/A to mcs, brade -
Yes, that did it I think.
bug_22659_v2(https://gitweb.torproject.org/user/gk/tor-browser.git/commit/?h=bug_22659_v2&id=4fe204ae57990582c306130b83e7d6911cae9527) in mytor-browserrepo has the backport for review.Given that the bug has been open for ages, I am not sure yet why we were not affected in ESR versions < 45.
Trac:
Keywords: TorBrowserTeam201801 deleted, TorBrowserTeam201801R added
Status: new to needs_review -
FWIW, it does not fix the issue on the blog, though. But I think this is okay for us as we can provide a reliable and supported method of achieving the same goal as the user tried to reach with the customization. I bet the underlying issue is another corner case regarding to language packs Mozilla has not fixed yet.