Mac OS: alpha channel upgrade is not smooth

On Mac OS, when I upgrade to Tor Browser 6.0a5 from an older version, it does not go well. After applying the MAR update and restarting, tor is not started and Tor Launcher displays this error: Unable to start tor The Tor executable is missing

Quitting and restarting a second time seems to fix the problem.

added TorBrowserTeam201605R component::applications/tor browser ff45-esr owner::tbb-team priority::high resolution::fixed severity::normal status::closed type::defect labels

Trac:
Description: On Mac OS, when I upgrade to Tor Browser 6.0a5 from an older version, it does not go well. After applying the MAR update and restarting, tor is not started and Tor Launcher displays this error: Unable to start tor

The Tor executable is missing

Quitting and restarting a second time seems to fix the problem.

to

On Mac OS, when I upgrade to Tor Browser 6.0a5 from an older version, it does not go well. After applying the MAR update and restarting, tor is not started and Tor Launcher displays this error: Unable to start tor The Tor executable is missing

Quitting and restarting a second time seems to fix the problem.

Kathy and I will have to do more debugging later, but it looks like the existing profile is not migrated at the time that the error message is displayed. I guess it must be using the old profile until the second restart.

During the failed startup, a TorBrowser-Data directory is created but it is nearly empty:

TorBrowser-Data/
  Browser/
    Caches/

My current guess at what is happening: the restart-after-update passes the location of the old profile via an env var (which causes it to be used when we do not want it to be), and that env var is cleared before the second restart (which causes a new profile to be created and our profile migration code to be executed).

I know we tested this, but maybe not correctly and probably not with an ESR45-based browser.

Trac:
Keywords: N/A deleted, TorBrowserTeam201604 added
Cc: brade to brade, gk

Before restart, XRE_PROFILE_PATH is set to the profile path. See: http://mxr.mozilla.org/mozilla-esr45/source/toolkit/xre/nsAppRunner.cpp#4419

This causes the SelectProfile() function to use that profile (and therefore our migration code never gets a chance to run). See: http://mxr.mozilla.org/mozilla-esr45/source/toolkit/xre/nsAppRunner.cpp#2333

The right fix is probably to ignore the XRE_PROFILE_PATH env variable if it contains the path of the old default profile location (.../TorBrowser.app/TorBrowser/Data/Browser/profile.default).

gk or boklm: We should add something to the TB 6.0a5 blog post to let people know to expect this problem (they should quit and start TB again to fix things).

Trac:
Cc: brade, gk to brade, gk, boklm
Keywords: N/A deleted, ff45-esr added

I updated the TB 6.0a5 blog post to mention this bug in the list of known issues.

Moving tickets

Trac:
Keywords: TorBrowserTeam201604 deleted, TorBrowserTeam201605 added

Here is our proposed fix: https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug18928-01&id=c6c784310e523bb49db0e8231a578a921d7cf101

Trac:
Keywords: TorBrowserTeam201605 deleted, TorBrowserTeam201605R added
Status: new to needs_review

Looks good to me. Arthur, care about having a look too?

Trac:
Cc: brade, gk, boklm to brade, gk, boklm, arthuredelstein

Looks good to me as well.

Applied to tor-browser-45.1.0esr-6.0-1 (commit d4f5d1c3704007cadaf6a37f3b8330f4e1930828).

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

closed

mentioned in issue #18947 (moved)

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