Use internal update URL for Torbutton

In #10682 (closed) we disabled update pings by setting the update URL to https://127.0.0.1 which caused #13129 (moved). We can do something more clever without sending pings AND causing #13129 (moved) as shown in comment:13:ticket:16200.

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

Trac:
Description: In #10682 (closed) we disabled update pings by setting the update URL to https://127.0.0.1 which caused #13129 (moved). We can do something more clever without sending pings AND causing #13129 (moved) as shown in comment13:ticket:16200.

to

In #10682 (closed) we disabled update pings by setting the update URL to https://127.0.0.1 which caused #13129 (moved). We can do something more clever without sending pings AND causing #13129 (moved) as shown in comment:13:ticket:16200.

Trac:
Summary: User internal update URL for Torbutton to Use internal update URL for Torbutton

Trac:
Cc: N/A to brade, mcs

bug_16427 (https://gitweb.torproject.org/user/gk/tor-launcher.git/commit/?h=bug_16428&id=06f135535fac7e79be9051229030d195a44c84a7) in my public TorLauncher repo has the fix. I see complaints in the console now about the update manifest not being valid XML but I think this is okay.

Trac:
Keywords: TorBrowserTeam201506 deleted, TorBrowserTeam201506R added
Status: new to needs_review

Replying to gk:

bug_16427 (https://gitweb.torproject.org/user/gk/tor-launcher.git/commit/?h=bug_16428&id=06f135535fac7e79be9051229030d195a44c84a7) in my public TorLauncher repo has the fix. I see complaints in the console now about the update manifest not being valid XML but I think this is okay.

Err, I meant https://gitweb.torproject.org/user/gk/torbutton.git/commit/?h=bug_16427 in my public Torbutton repo.

r=mcs

Is there a reason why we need the comma after the data url? Is that related to the XML warnings?

Replying to mikeperry:

Is there a reason why we need the comma after the data url? Is that related to the XML warnings?

The comma is required to separate the content type from the data URL payload (which in our case is an empty string). See section 3 of https://tools.ietf.org/html/rfc2397. I think the XML warning occurs because the document (text) is empty, which means that request.responseXML is null or undefined. But we do not want a non-empty XML document, because then the code will probably get as far as trying to check for a signature and try to verify it using the updateKey... which we do not have.

So... I think this is the best we can do without patching the code inside toolkit/mozapps/extensions/internal/AddonUpdateChecker.jsm. If you want to follow the execution patch, start at the checkForUpdates() function within that file. If I was going to patch something, I would modify UpdateParser.onLoad() to accept (and ignore) a zero-length document (request.responseText == ""). I am not sure if Mozilla would like that idea or not.

Ok, I went ahead and merged this. I've also noticed a lot of noise accumulating in our error console, so perhaps we should just file a new ticket to work on that.

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

closed

mentioned in issue #16442 (moved)

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

mentioned in issue tpo/applications/tor-browser#16442