Opened 18 months ago

Closed 10 months ago

Last modified 7 months ago

#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 18 months ago by 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.

comment:2 Changed 18 months ago by 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.

comment:3 in reply to:  2 Changed 18 months ago by 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.

comment:4 Changed 18 months ago by 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.

comment:5 in reply to:  4 Changed 18 months ago by 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)...

comment:6 Changed 18 months ago by gk

Happens on a Windows 7 machine as well.

comment:7 Changed 18 months ago by 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.

comment:8 Changed 18 months ago by 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.

comment:9 Changed 18 months ago by cypherpunks

comment:10 in reply to:  9 Changed 18 months ago by 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.

comment:11 Changed 18 months ago by gk

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

comment:12 Changed 18 months ago by 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...

comment:13 Changed 18 months ago by cypherpunks

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

comment:14 Changed 18 months ago by gk

Keywords: TorBrowserTeam201707 added; TorBrowserTeam201706 removed

Moving Tickets to July 2017.

comment:15 Changed 18 months ago by gk

Keywords: GeorgKoppen201707 added; GeorgKoppen201706 removed

Moving my tickets to July 2017.

comment:16 Changed 17 months ago by gk

Keywords: TorBrowserTeam201708 added; TorBrowserTeam201707 removed

Moving our Tickets to August.

comment:17 Changed 17 months ago by gk

Keywords: GeorgKoppen201708 added; GeorgKoppen201707 removed

Moving my tickets to August.

comment:18 Changed 15 months ago by gk

Keywords: GeorgKoppen201709 added; GeorgKoppen201708 removed

Moving my tickets to the new month.

comment:19 Changed 15 months ago by gk

Keywords: TorBrowserTeam201709 added; TorBrowserTeam201708 removed

Items for September 2017.

comment:20 Changed 15 months ago by gk

Keywords: TorBrowserTeam201710 added; TorBrowserTeam201709 removed

Items for October 2017

comment:21 Changed 15 months ago by gk

Keywords: GeorgKoppen201710 added; GeorgKoppen201709 removed

comment:22 Changed 13 months ago by gk

Keywords: GeorgKoppen201711 added; GeorgKoppen201710 removed

Moving my tickets to November.

comment:23 Changed 13 months ago by gk

Keywords: TorBrowserTeam201711 added; TorBrowserTeam201710 removed

Moving tickets over to November.

comment:24 Changed 12 months ago by gk

Moving tickets to December 2017

comment:25 Changed 12 months ago by gk

Keywords: TorBrowserTeam201712 added; TorBrowserTeam201711 removed

Moving tickets to December 2017, for realz.

comment:26 Changed 12 months ago by gk

Keywords: GeorgKoppen201712 added; GeorgKoppen201711 removed

Moving my tickets to December.

comment:27 Changed 11 months ago by gk

Keywords: GeorgKoppen201801 added; GeorgKoppen201712 removed

Moving my tickets to 2018

comment:28 Changed 11 months ago by gk

Keywords: TorBrowserTeam201801 added; TorBrowserTeam201712 removed

Moving tickets to 2018.

comment:29 Changed 11 months ago by gk

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 11 months ago by gk

Keywords: TorBrowserTeam201801R added; TorBrowserTeam201801 removed
Status: newneeds_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 11 months ago by 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.

comment:32 Changed 10 months ago by gk

Keywords: TorBrowserTeam201802R added; TorBrowserTeam201801R removed

Moving reviews to February.

comment:33 Changed 10 months ago by 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.

comment:34 Changed 10 months ago by gk

Resolution: fixed
Status: needs_reviewclosed

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

comment:35 Changed 10 months ago by gk

Keywords: tbb-backport added

comment:36 Changed 7 months ago by gk

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.

Note: See TracTickets for help on using tickets.