Opened 5 years ago

Closed 5 years ago

#13245 closed defect (fixed)

language pack lost after update

Reported by: mcs Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Keywords: TorBrowserTeam201409
Cc: brade Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

When using the automatic updater to go from TB 4.0-alpha-2 to 4.0-alpha-3 the language pack extension seems to be lost.

Tested with the 4.0-alpha-2 es-ES build and MAR files from https://people.torproject.org/~mikeperry/builds/4.0-alpha-3/

My guess is that the MAR file was not created correctly. I will investigate.

Child Tickets

Attachments (1)

bug13245-patch.txt (4.5 KB) - added by mcs 5 years ago.
possible fix (untested)

Download all attachments as: .zip

Change History (10)

comment:1 Changed 5 years ago by mcs

The problem is not in the MAR file. What is happening is that the update URL contains en-US instead of es-ES. Apparently, setting the general.useragent.locale pref to es-ES is not enough to cause the %LOCALE% pattern in app.update.url to be replaced with es-ES (this makes sense for Firefox but not for Tor Browser). brade and I will work on a fix.

comment:2 in reply to:  1 Changed 5 years ago by mcs

Replying to mcs:

The problem is not in the MAR file. What is happening is that the update URL contains en-US instead of es-ES.

Which (I meant to explain) causes the en-US MAR file to be downloaded and applied instead of the Spanish one.

comment:3 Changed 5 years ago by mcs

The fix is to re-populate the contents of a file named update.locale (located within the top-level omni.ja file). This needs to be done during the locale packaging that is done within gitian/descriptors/*/gitian-bundle.yml I have a patch that I am testing now.

The code in nsUpdateService.js reads the contents of this file and uses that when replacing %LOCALE% within the update URL. We can fix this for 4.0-alpha-3 but I am not sure what to do about 4.0-alpha-2 (non en-US bundles will be "upgraded" to en-US bundles). One that happens, users will have to download a new non-English copy of TB.

comment:4 Changed 5 years ago by mikeperry

Well, it sounds like 4.0a2 users will already be bitten by this, and there is nothing we can do about that, short of disabling the updater. We just have to warn people on the blog (which is rough, because that will only reach English speakers already).

I am thinking that if we can get a fix together by tonight, then we can hold 4.0a3 another day.. but otherwise, we'll just have to warn people twice instead of once..

Changed 5 years ago by mcs

Attachment: bug13245-patch.txt added

possible fix (untested)

comment:5 in reply to:  4 Changed 5 years ago by mcs

Replying to mikeperry:

I am thinking that if we can get a fix together by tonight, then we can hold 4.0a3 another day.. but otherwise, we'll just have to warn people twice instead of once..

I attached a possible fix. But it is untested because:
(1) I don't have a partial 4.0-alpha-3 build to start from so I am starting from scratch and
(2) I had to step out for a while and of course the build I started before I left failed early.

It might be faster for you or gk to apply this patch and re-package the build by re-running the bundle step. The biggest danger is that my untested code is wrong.

Once anyone has some builds, brade and/or I can do some testing, although anyone can do the following with a non en-US build to verify that this fix is correct:
a) use about:config to set set app.update.log = true
b) open the browser console (Shift+Ctrl+J) and clear it
c) open the about box and click "Check for Updates"
Then look on the console and see if the update URL that was accessed includes the language, e.g., es-ES.

My build just failed again so I will have to try to debug it (I am not remotely close to the bundle step yet).

comment:6 Changed 5 years ago by mikeperry

ok, I should be able to rebundle 4.0a3 with this quickly and get a build up in my homedir in a couple hours (slow upload). I imagine you'll be asleep, but we can at least decide by tonight if this version is better, the same, or worse than 4.0a3-build2.

comment:7 Changed 5 years ago by mikeperry

Ok, it looks like the request was sent to https://www.torproject.org/dist/torbrowser/update_2/alpha/Linux_x86_64-gcc3/4.0-alpha-3/es-ES?force=1.

I think this means we're good! Thanks a lot for the quick work here!

comment:8 Changed 5 years ago by brade

Great news! I can sleep now. :-)

comment:9 Changed 5 years ago by mcs

Keywords: TorBrowserTeam201409 added
Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.