In Tor Browser 7 users were able to extract Tor Browser in directory foo run it and copy it over to bar and run it. Starting with Tor Browser 8 this does not seem to be possible anymore. See, for instance, the respective report on our blog: https://blog.torproject.org/comment/277011#comment-277011.
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
Kathy and I cannot reproduce the crash, but any action that causes the browser profile to be renamed or moved breaks things. The specific problem which we observed on both macOS and Linux is that Torbutton and Tor Launcher are not loaded after a rename or move.
A workaround is to delete the extensions.json file, which contains full paths. Probably that file is supposed to be recreated automatically when the profile is moved. Webextensions do not seem to suffer the same fate even though extensions.json contains their paths as well (which are outdated after the profile move).
Trac: Summary: Relocating the Tor Browser directory is broken with Tor Browser 8 on Linux to Relocating the Tor Browser directory is broken with Tor Browser 8
why isn't this fixed already? my tor browser is up to date and if i move the folder somewhere else than the location where i first installed it and try to launch the program i can't get it to work. i thought tor was supposed to be portable
why isn't this fixed already? my tor browser is up to date and if i move the folder somewhere else than the location where i first installed it and try to launch the program i can't get it to work. i thought tor was supposed to be portable
It isn't fixed yet because nobody has worked on it so far. But it could be you to solve this, helping us out! It would be really appreciated.
A more permanent workaround for me was to delete extensions.json, create an empty 0 KB file in its place, and mark it as read-only. That forced the browser to use a temporary extensions.json for each session, and kept me from having to delete the file every time the directory changed.
A more permanent workaround for me was to delete extensions.json, create an empty 0 KB file in its place, and mark it as read-only. That forced the browser to use a temporary extensions.json for each session, and kept me from having to delete the file every time the directory changed.
Wow, that's painful. I guess what we could do is patching XPIProviderUtils.js's parseDB() and add a sanity check making sure the path of the extensions in the DB exists. If not we need to recreate the DB. I suspect that would be something Mozilla would take if we upstreamed it.
We could as well just delete the json file during browser shutdown. However, that seems to be a bit too excessive.
FWIW, John Haller from PortableApps applied a fix (see https://portableapps.com/node/60299 , and comment 9), but I'm not entirely sure what he did, but also had an additional issue (see https://portableapps.com/node/60496 ) with addonStartup.json.lz4 (edit: which was added in FF67).
Let me know if you would like me to reach out to John Halter and ask what he did, but I think you know what needs to be done already, and getting this done upstream is the best solution IMO.
So, this was broken in 8.x in a way that makes the whole experience failing hard which is kind of good. I wonder how the breakage will look like in 9.0 given that Tor Launcher and Torbutton are now no separate extensions anymore. The fear here is that the user retains now a somewhat usable Tor Browser but broken in subtle and dangerous ways. We should double-check that and fix it if necessary.
This problem still exists with Tor Browser 9.0a8. After renaming the profile directory, HTTPS-E and NoScript are both broken. On macOS we had to remove the following three files in order to make things work again (I assume this is also true for Windows and Linux, although the file paths are different):
For webext.sc.lz4, we could use a similar solution: we could modify _readData() inside components/extensions/ExtensionParent.jsm to check extension paths and ignore the cached data if one or more files pointed to by the paths no longer exist.
For addonStartup.json.lz4, we could again use a similar solution: we could modify loadExtensionState() inside toolkit/mozapps/extensions/internal/XPIProvider.jsm to check extension paths and ignore the cached data if paths have changed.
All of the above said, it is too risky to fix this in Tor Browser 9.0. Maybe something for 9.5alpha?