#22659 closed defect (fixed)
Changes to `intl.accept.languages` get overwritten after restart
Reported by: | gk | Owned by: | tbb-team |
---|---|---|---|
Priority: | Medium | Milestone: | |
Component: | Applications/Tor Browser | Version: | |
Severity: | Normal | Keywords: | tbb-7.0-issues, tbb-regression, GeorgKoppen201801, TorBrowserTeam201802R, tbb-backported |
Cc: | mcs, brade | Actual Points: | |
Parent ID: | Points: | ||
Reviewer: | Sponsor: |
Description
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.
Child Tickets
Change History (36)
comment:1 Changed 20 months ago by
comment:2 follow-up: 3 Changed 20 months ago by
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.
comment:3 Changed 20 months ago by
Replying to mcs:
How can I reproduce this bug? I tried toggling
extensions.torbutton.spoof_english
within 7.0.1 on OSX, andintl.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.
comment:4 follow-up: 5 Changed 20 months ago by
So far I cannot reproduce this problem when testing on OSX without the patch for #21999. 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
Conectar
during startup. - Opened about:config and noted that the value for
intl.accept_languages
wasen-US, en
as expected. - Used about:config to toggle
extensions.torbutton.spoof_english
tofalse
and noted that theintl.accept_languages
value had been changed toes-ES, es, en-US, en
(the default value). - Restarted the browser and checked the
intl.accept_languages
one more time. The value was stilles-ES, es, en-US, en
.
comment:5 Changed 20 months ago by
Replying to mcs:
So far I cannot reproduce this problem when testing on OSX without the patch for #21999. 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
Conectar
during startup.- Opened about:config and noted that the value for
intl.accept_languages
wasen-US, en
as expected.- Used about:config to toggle
extensions.torbutton.spoof_english
tofalse
and noted that theintl.accept_languages
value had been changed toes-ES, es, en-US, en
(the default value).- Restarted the browser and checked the
intl.accept_languages
one more time. The value was stilles-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)...
comment:7 Changed 20 months ago by
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.
comment:8 Changed 20 months ago by
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.
comment:9 follow-up: 10 Changed 20 months ago by
Others enjoy it too https://bugzilla.mozilla.org/show_bug.cgi?id=654099
comment:10 Changed 20 months ago by
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.
comment:11 Changed 20 months ago by
Firefox 51 is the first version showing something funky wrt this bug. I'll try to narrow things further down.
comment:12 Changed 20 months ago by
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...
comment:14 Changed 20 months ago by
Keywords: | TorBrowserTeam201707 added; TorBrowserTeam201706 removed |
---|
Moving Tickets to July 2017.
comment:15 Changed 20 months ago by
Keywords: | GeorgKoppen201707 added; GeorgKoppen201706 removed |
---|
Moving my tickets to July 2017.
comment:16 Changed 19 months ago by
Keywords: | TorBrowserTeam201708 added; TorBrowserTeam201707 removed |
---|
Moving our Tickets to August.
comment:17 Changed 19 months ago by
Keywords: | GeorgKoppen201708 added; GeorgKoppen201707 removed |
---|
Moving my tickets to August.
comment:18 Changed 18 months ago by
Keywords: | GeorgKoppen201709 added; GeorgKoppen201708 removed |
---|
Moving my tickets to the new month.
comment:19 Changed 18 months ago by
Keywords: | TorBrowserTeam201709 added; TorBrowserTeam201708 removed |
---|
Items for September 2017.
comment:20 Changed 17 months ago by
Keywords: | TorBrowserTeam201710 added; TorBrowserTeam201709 removed |
---|
Items for October 2017
comment:21 Changed 17 months ago by
Keywords: | GeorgKoppen201710 added; GeorgKoppen201709 removed |
---|
comment:22 Changed 16 months ago by
Keywords: | GeorgKoppen201711 added; GeorgKoppen201710 removed |
---|
Moving my tickets to November.
comment:23 Changed 16 months ago by
Keywords: | TorBrowserTeam201711 added; TorBrowserTeam201710 removed |
---|
Moving tickets over to November.
comment:25 Changed 15 months ago by
Keywords: | TorBrowserTeam201712 added; TorBrowserTeam201711 removed |
---|
Moving tickets to December 2017, for realz.
comment:26 Changed 15 months ago by
Keywords: | GeorgKoppen201712 added; GeorgKoppen201711 removed |
---|
Moving my tickets to December.
comment:27 Changed 14 months ago by
Keywords: | GeorgKoppen201801 added; GeorgKoppen201712 removed |
---|
Moving my tickets to 2018
comment:28 Changed 14 months ago by
Keywords: | TorBrowserTeam201801 added; TorBrowserTeam201712 removed |
---|
Moving tickets to 2018.
comment:29 Changed 13 months ago by
Cc: | mcs brade added |
---|
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.
comment:30 Changed 13 months ago by
Keywords: | TorBrowserTeam201801R added; TorBrowserTeam201801 removed |
---|---|
Status: | new → needs_review |
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.
comment:31 Changed 13 months ago by
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.
comment:32 Changed 13 months ago by
Keywords: | TorBrowserTeam201802R added; TorBrowserTeam201801R removed |
---|
Moving reviews to February.
comment:33 Changed 12 months ago by
r=brade, r=mcs
The backported patch matches what Mozilla did and it fixes the problem where the wrong Accept-Language header was sent.
comment:34 Changed 12 months ago by
Resolution: | → fixed |
---|---|
Status: | needs_review → closed |
Thanks. Cherry-picked to tor-browser-52.6.0esr-8.0-2
(commit 0445d514609fd71e1aad90f67af8355825cda929).
comment:35 Changed 12 months ago by
Keywords: | tbb-backport added |
---|
comment:36 Changed 10 months ago by
Keywords: | tbb-backported added; tbb-backport removed |
---|
Backported to tor-browser-52.8.0esr-7.5-1
(commit 724133ad5d58124b2eaf236bfc65f46bf54bbe8a). Should be available in 7.5.4.
There is nothing obviously wrong with the logic. The same works in Tor Browser 6.5.x but in Tor Browser 7 doing
does not give us back the
intl.accept_languages
value 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.