"TorBrowser update failed" dialog showed up although no update was tried

Today morning I got greeted by the "TorBrowser update failed" dialog explaining me that the update failed and I should make sure I have the latest version installed pointing me to the download easy page. I wonder how this could have happened? I clicked sometimes on the update button to look at the log the days before. If that is the issue then I wonder what triggered the dialog today and not, say, yesterday.

Apart from that one nit: the dialog was talking about the "TorBrowser" while the about:tor page in the background was talking about "Tor Browser". Not sure which one is better but it should be only one we use.

added component::applications/tor browser owner::tbb-team priority::medium resolution::fixed status::closed type::defect labels

We did not know it, but the browser will display the "update failed" dialog after a background update check fails 10 times. You must have reached that threshold. See:

http://mxr.mozilla.org/mozilla-esr24/source/toolkit/mozapps/update/nsUpdateService.js#2295

Because of this issue, I think we need to deploy files generated by boklm's script (https://github.com/boklm/tb-update-response) under https://www.torproject.org/dist/torbrowser/update/ ASAP. Who has access to the web site to make that happen?

Related to "TorBrowser" vs. "Tor Browser", I think we should use "Tor Browser". Most occurrences of the variant without the space come from our setting for MOZ_APP_DISPLAYNAME inside our .mozconfig files. Should we add the space?

Replying to mcs:

Because of this issue, I think we need to deploy files generated by boklm's script (https://github.com/boklm/tb-update-response) under https://www.torproject.org/dist/torbrowser/update/ ASAP. Who has access to the web site to make that happen?

It turns out that boklm's script does not provide a way to generate the "no update needed" update manifest files that we need. I hacked it a little and generated the necessary files, which I will attach to this ticket as a zip archive. The files contained within need to be placed under the correct place so they are served up under https://www.torproject.org/dist/torbrowser/update/

Once that is done, you can test things by setting app.update.log to true in TB 4.0a2, opening the TB about box, and clicking "Check for Updates". The browser console should show lines similar to:

[16:20:06.159] AUS:SVC Checker:onLoad - request completed downloading document [16:20:06.159] AUS:SVC Checker:onLoad - number of updates available: 0

Trac:
Cc: mcs, brade to mcs, brade, boklm

Trac:
dist-torbrowser-update-no-updates.zip

htdocs for 4.0-alpha-2 when no update is available

Replying to mcs:

It turns out that boklm's script does not provide a way to generate the "no update needed" update manifest files that we need.

I updated the script so that it answers with "no updates" when we are running the latest version: https://github.com/boklm/tb-update-response/commit/d12c5c7abb99798a0e0642e56fb2725aa99e679a

Replying to boklm:

I updated the script so that it answers with "no updates" when we are running the latest version: https://github.com/boklm/tb-update-response/commit/d12c5c7abb99798a0e0642e56fb2725aa99e679a

Thanks! By using an empty releases/4.0-alpha-2 directory, I was able to generate a much smaller set of files for placing on www.torproject.org. I will replace the attachment with a new archive that contains the new files.

Trac:
dist-torbrowser-update-no-updates.2.zip

 htdocs for 4.0-alpha-2 when no update is available

I guess trac didn't replace the old attachment with the new one I uploaded (maybe because I do not have permission to delete attachments)? Anyway, dist-torbrowser-update-no-updates.2.zip is the correct zip file (it only contains two files -- .htaccess and no-update.xml).

Because he is awesome, Mike deployed the files to the web site. I filed #13091 (moved) for the "Tor[space]Browser" issue.

Trac:
Status: new to closed
Resolution: N/A to fixed

I am greeted by this dialog using 4.0a3, too. Is that (still a bug) in our code or some missing files again?

Trac:
Resolution: fixed to N/A
Status: closed to reopened

The XML response files need to be uploaded to the 'update_2' directory.

Replying to boklm:

The XML response files need to be uploaded to the 'update_2' directory.

Ugh. For some reason I thought this was done (I checked the update/ files that are used by TB 4.0-alpha-2 and mistakenly assumed the update_2/ files were in place).

Can someone who has access to the tpo web server do this? I will attach the files boklm sent out in email on 9/26/14.

Trac:
update_2.tar.gz

update_2/ files for TB 4.0-alpha-3

I am confused. I thought that until we actually had an update, all we needed was the no-update.xml file?

I have added these xml files, but they seem to say that 4.0-alpha-3 users are supposed to be updating to 4.0-alpha-3. Are we sure this is correct?

Replying to mikeperry:

I am confused. I thought that until we actually had an update, all we needed was the no-update.xml file?

I have added these xml files, but they seem to say that 4.0-alpha-3 users are supposed to be updating to 4.0-alpha-3. Are we sure this is correct?

This URL for alpha-3 users says that there is no update, so this is correct: https://www.torproject.org/dist/torbrowser/update_2/alpha/Linux_x86-gcc3/4.0-alpha-3/en-US

This one for alpha-2 users says that there is an update: https://www.torproject.org/dist/torbrowser/update_2/alpha/Linux_x86-gcc3/4.0-alpha-2/en-US

Because of the update -> update_2 directory change, alpha-2 users won't load this URL this time, so we could have stayed with only the no-update.xml and an .htaccess files, but it seems that the .htaccess file to do the redirection was missing.

Replying to boklm:

Because of the update -> update_2 directory change, alpha-2 users won't load this URL this time, so we could have stayed with only the no-update.xml and an .htaccess files, but it seems that the .htaccess file to do the redirection was missing.

So for now Mike could: rm update_2/4.0-alpha-3* (I think).

When we ship 4.0-alpha-4, everything inside update_2/ will need to be replaced with the newly generated files (remove everything and put the new files in place).

Assuming this is fixed again. Closing.

Trac:
Status: reopened to closed
Resolution: N/A to fixed

closed

mentioned in issue #13091 (moved)

moved to tpo/applications/tor-browser#13087 (closed)

mentioned in issue tpo/applications/tor-browser#13091 (closed)