Changes to `intl.accept.languages` get overwritten after restart

[gk]

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.

[gk]

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_languages value which is in chrome://global/locale/intl.properties (in case one has a non-en-US bundle) but en-US, en. It's not clear yet where that new value is coming from.

[mcs]

How can I reproduce this bug? I tried toggling extensions.torbutton.spoof_english within 7.0.1 on OSX, and intl.accept_languages was correctly updated.

[gk]

Replying to mcs:

How can I reproduce this bug? I tried toggling extensions.torbutton.spoof_english within 7.0.1 on OSX, and intl.accept_languages was 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 but it is not related to it.

[mcs]

So far I cannot reproduce this problem when testing on OSX without the patch for #21999. Here is what I did:

1. Opened a clean copy of the es-ES variant of Tor Browser 7.0.1 (no preexisting TorBrowser-Data directory).
2. Clicked Conectar during startup.
3. Opened about:config and noted that the value for intl.accept_languages was en-US, en as expected.
4. Used about:config to toggle extensions.torbutton.spoof_english to false and noted that the intl.accept_languages value had been changed to es-ES, es, en-US, en (the default value).
5. Restarted the browser and checked the intl.accept_languages one more time. The value was still es-ES, es, en-US, en.

[gk]

Replying to mcs:

So far I cannot reproduce this problem when testing on OSX without the patch for #21999. Here is what I did:

1. Opened a clean copy of the es-ES variant of Tor Browser 7.0.1 (no preexisting TorBrowser-Data directory).
2. Clicked Conectar during startup.
3. Opened about:config and noted that the value for intl.accept_languages was en-US, en as expected.
4. Used about:config to toggle extensions.torbutton.spoof_english to false and noted that the intl.accept_languages value had been changed to es-ES, es, en-US, en (the default value).
5. Restarted the browser and checked the intl.accept_languages one more time. The value was still es-ES, es, en-US, en.

I followed those five steps and I get en-US, en as result. Could you test on a Linux box (I did that)? Maybe that's the difference (although this would be even weirder)...

[gk]

Happens on a Windows 7 machine as well.

[gk]

Querying chrome://global/locale/intl.properties at the beginning of torbutton_update_fingerprinting_prefs() gives me en-US, en after restart for intl.accept_languages while entering chrome://global/locale/intl.properties into the URL bar gives me de, en-US, en as it should be the case. Huh.

[mcs]

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, fr and seeing that when this bug occurs the "default" value is indeed en-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. The general.useragent.locale pref does not seem to be suffer from the same bug even though its value should be determined by the same mechanism.

[cypherpunks]

Others enjoy it too ​https://bugzilla.mozilla.org/show_bug.cgi?id=654099

[mcs]

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.properties showing up (as a string)? I think this ticket covers a different but possibly related problem.

[gk]

Firefox 51 is the first version showing something funky wrt this bug. I'll try to narrow things further down.

[gk]

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...

[cypherpunks]

Nothing seems related in it. Does that happen in non-e10s mode?

[gk]

Moving Tickets to July 2017.

[gk]

Moving my tickets to July 2017.

[gk]

Moving our Tickets to August.

[gk]

Moving my tickets to August.

[gk]

Moving my tickets to the new month.

[gk]

Items for September 2017.

[gk]

Items for October 2017

[gk]

Moving my tickets to November.

[gk]

Moving tickets over to November.

[gk]

Moving tickets to December 2017

[gk]

Moving tickets to December 2017, for realz.

[gk]

Moving my tickets to December.

[gk]

Moving my tickets to 2018

[gk]

Moving tickets to 2018.

[gk]

An update on that one: It seems there are different issues here at work. The one is that the intl.accept_languages pref 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.

[gk]

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 my tor-browser repo 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.

[gk]

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.

[gk]

Moving reviews to February.

[mcs]

r=brade, r=mcs
The backported patch matches what Mozilla did and it fixes the problem where the wrong Accept-Language header was sent.

[gk]

Thanks. Cherry-picked to tor-browser-52.6.0esr-8.0-2 (commit 0445d514609fd71e1aad90f67af8355825cda929).

[gk]

Backported to tor-browser-52.8.0esr-7.5-1 (commit 724133ad5d58124b2eaf236bfc65f46bf54bbe8a). Should be available in 7.5.4.