[tor-bugs] #27604 [Applications/Tor Browser]: Relocating the Tor Browser directory is broken with Tor Browser 8
Tor Bug Tracker & Wiki
blackhole at torproject.org
Wed Oct 30 13:28:47 UTC 2019
#27604: Relocating the Tor Browser directory is broken with Tor Browser 8
-------------------------------------------------+-------------------------
Reporter: gk | Owner: tbb-
| team
Type: defect | Status:
| needs_review
Priority: High | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Major | Resolution:
Keywords: tbb-8.0-issues, tbb-regression, | Actual Points: 0.6
tbb-8.0.1-can, TorBrowserTeam201910R |
Parent ID: | Points: 0.5
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Changes (by acat):
* status: new => needs_review
* keywords: tbb-8.0-issues, tbb-regression, tbb-8.0.1-can,
TorBrowserTeam201910 => tbb-8.0-issues, tbb-regression, tbb-8.0.1-can,
TorBrowserTeam201910R
Comment:
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).
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/27604#comment:32>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list