[tor-bugs] #27604 [Applications/Tor Browser]: Relocating the Tor Browser directory is broken with Tor Browser 8

[Tor Bug Tracker & Wiki]

#27604: Relocating the Tor Browser directory is broken with Tor Browser 8
-------------------------------------------------+-------------------------
 Reporter:  gk                                   |          Owner:  tbb-
                                                 |  team
     Type:  defect                               |         Status:
                                                 |  needs_revision
 Priority:  High                                 |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Major                                |     Resolution:
 Keywords:  tbb-8.0-issues, tbb-regression,      |  Actual Points:  3
  tbb-8.0.1-can, TorBrowserTeam201910            |
Parent ID:                                       |         Points:  0.5
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------
Changes (by gk):

 * status:  needs_review => needs_revision
 * keywords:  tbb-8.0-issues, tbb-regression, tbb-8.0.1-can,
     TorBrowserTeam201910R => tbb-8.0-issues, tbb-regression,
     tbb-8.0.1-can, TorBrowserTeam201910


Comment:

 Replying to [comment:32 acat]:
 > Patch for review: https://github.com/acatarineu/tor-browser/commit/27604
 >
 > I think there are (at least) three different issues here:
 >
 > One is the problem of extensions being broken that mcs mentioned, which
 I think was introduced by
 https://bugzilla.mozilla.org/show_bug.cgi?id=1512436. More concretely, the
 problem seems to be the new `rootURI` field in `addonStartup.json` which
 is absolute, unlike the `path` one which is serialized as relative:
 https://searchfox.org/mozilla-
 esr68/rev/22bae08f58d48ff86e02d5bbd12e5630af148d6f/toolkit/mozapps/extensions/internal/XPIProvider.jsm#555.
 I think this was needed to have built-in addons with `resource://`
 `rootURI` like `resource://gre/modules/themes/default/`. Fixed this by
 always overriding  it [https://searchfox.org/mozilla-
 esr68/rev/22bae08f58d48ff86e02d5bbd12e5630af148d6f/toolkit/mozapps/extensions/internal/XPIProvider.jsm#488
 here] if `this.file` exists (should not happen with addons with
 `resource://` rootURIs).
 >
 > The other is some special treatment that langpacks get due to
 https://bugzilla.mozilla.org/show_bug.cgi?id=1492459. These are flagged as
 `missing` early [https://searchfox.org/mozilla-
 esr68/rev/22bae08f58d48ff86e02d5bbd12e5630af148d6f/toolkit/mozapps/extensions/internal/XPIProvider.jsm#502
 here] (`currentModifiedTime` is set [https://searchfox.org/mozilla-
 esr68/source/toolkit/mozapps/extensions/AddonManagerStartup.cpp#445 here]
 only for langpacks) if the (old) path of the extension xpi does not exist.
 If that's the case the langpack is removed in https://searchfox.org
 /mozilla-
 esr68/rev/715f10032bb8be971ff0e9846e12be58afad4950/toolkit/mozapps/extensions/internal/XPIDatabase.jsm#3143.
 That  seems to fallback to English, but on browser restart it's completely
 broken, showing the same error message mentioned in comment:29 and in
 bugzilla.  I'm not so sure what's the best way to fix this, in the
 proposed patch I'm checking for the (new) extension file existing before
 flagging it as missing.
 >
 > Third is the issue of `extensions.json` (and possibly `webext.sc.lz4`)
 paths not being updated, but I'm not so sure this has functionality impact
 if the two previous issues are fixed. In any case, I think making
 `scanForChanges` return `true` when the path of some addon location has
 changed will do the trick here and trigger an update of `extensions.json`.
 I verified that `webext.sc.lz4` paths are also updated, although I did not
 investigate what exactly in the code is updating the latter.
 >
 > With the patch I cannot reproduce the issues anymore, verified on Linux
 and Windows. I also verified that a profile which is in the bad state of
 comment:29 is fixed.
 >
 > I think it's worth filing bugzillas or updating the existing ones and
 try to get this fixed in Firefox (and also get some feedback on the
 suggested patches).

 Yes, please do update https://bugzilla.mozilla.org/show_bug.cgi?id=1429838
 so we can get some feedback here as well.

 That said this looks pretty good. One thing we should fix is getting
 {{{
 JavaScript error: resource://gre/modules/ExtensionCommon.jsm, line 2318:
 Error: listener not re-registered
 JavaScript error: resource://gre/modules/ExtensionCommon.jsm, line 2318:
 Error: listener not re-registered
 JavaScript error: resource://gre/modules/ExtensionCommon.jsm, line 2318:
 Error: listener not re-registered
 JavaScript error: resource://gre/modules/ExtensionCommon.jsm, line 2318:
 Error: listener not re-registered
 JavaScript error: resource://gre/modules/ExtensionCommon.jsm, line 2318:
 Error: listener not re-registered
 JavaScript error: resource://gre/modules/ExtensionCommon.jsm, line 2318:
 Error: listener not re-registered
 JavaScript error: resource://gre/modules/ExtensionCommon.jsm, line 2318:
 Error: listener not re-registered
 JavaScript error: resource://gre/modules/ExtensionCommon.jsm, line 2318:
 Error: listener not re-registered
 }}}
 after applying your patches. (I blew the startup cache in the profile
 directory away before I started a Tor Browser modified with your patches)
 Re-locating does not matter I start to get those JS errors even if I keep
 the current location.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/27604#comment:36>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online