Adapt torbutton to TBB/FF52ESR

Various changes to torbutton will need to be made to work properly with the Firefox 52 ESR-based Tor Browser.

added TorBrowserTeam201703 component::applications/tor browser ff52-esr owner::tbb-team parent::20680 priority::medium resolution::fixed severity::normal sponsor::4 status::closed tbb-7.0-must tbb-7.0-must-nightly tbb-torbutton type::defect labels

Trac:
Cc: N/A to brade, mcs

Here's my current branch: https://github.com/arthuredelstein/torbutton/commits/21201+1

Kathy and I also noticed that the circuit display code triggers a crash in our debug build when e10s is enabled. This happens because GetProxyInfo is not implemented by HttpChannelChild (the getSOCKSCredentialsForBrowser() function tries to access channel.proxyInfo; on the browser side, see: https://github.com/arthuredelstein/tor-browser/blob/20680%2B2/netwerk/protocol/http/HttpChannelChild.cpp#L2395).

Should I file a new ticket for this issue or will it be covered by this ticket?

Also, here is a related question: should we make this the parent bug for #21267 (moved) and #21268 (moved) or do we want to track e10s issues separately?

Trac:
Keywords: N/A deleted, tbb-torbutton, ff52-esr added

Trac:
Keywords: N/A deleted, TorBrowserTeam201702 added

This is Sponsor4 work

Trac:
Sponsor: N/A to Sponsor4

Replying to mcs:

Kathy and I also noticed that the circuit display code triggers a crash in our debug build when e10s is enabled. This happens because GetProxyInfo is not implemented by HttpChannelChild (the getSOCKSCredentialsForBrowser() function tries to access channel.proxyInfo; on the browser side, see: https://github.com/arthuredelstein/tor-browser/blob/20680%2B2/netwerk/protocol/http/HttpChannelChild.cpp#L2395).

Should I file a new ticket for this issue or will it be covered by this ticket?

I will look into this here and if turns into a big issue I can open a new ticket.

Also, here is a related question: should we make this the parent bug for #21267 (moved) and #21268 (moved) or do we want to track e10s issues separately?

Seems reasonable to make this the parent bug.

Here is an additional small fix (needed for e10s compatibility): https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug21201-01&id=b5b4dd067aaea6f9eee79eca249d56b6bd636a08

Replying to mcs:

Here is an additional small fix (needed for e10s compatibility): https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug21201-01&id=b5b4dd067aaea6f9eee79eca249d56b6bd636a08

I should have mentioned that the reason it is okay to remove the "No initial browser content window?" code is because it is leftover from the pre-#19459 era; Kathy and I do not see a need for it any longer.

Trac:
Keywords: N/A deleted, tbb-7.0-must added

Moving tickets to March

Trac:
Keywords: TorBrowserTeam201702 deleted, TorBrowserTeam201703 added

Replying to mcs:

Here is an additional small fix (needed for e10s compatibility): https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug21201-01&id=b5b4dd067aaea6f9eee79eca249d56b6bd636a08

This looks good to me. I added it to my branch for this ticket: https://github.com/arthuredelstein/torbutton/commits/21201+1

Here's the latest branch: https://github.com/arthuredelstein/torbutton/commits/21201+3

We want those tickets for our first ESR52 nightlies.

Trac:
Keywords: N/A deleted, tbb-7.0-must-nightly added

Okay, all the child tickets are resolved. I added the multiprocessCompatible flag in 7c8c20ff3b4f6747d57c259407a55194ffb62374. That might help us with our testing. We can revert that later if we think we found blockers and can't fix them until a release has to get out.

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

closed

mentioned in issue #21267 (moved)

mentioned in issue #21268 (moved)

mentioned in issue #21547 (moved)

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