We need to move away from our XPCOM extensions, Tor Launcher being one of them. As for Tor Browser it might be hard/impossible, if we tried to reimplement everything Tor Launcher does with the WebExtensions API. Instead we plan to integrate it tighter into the browser itself making use of its capabilities.
This ticket is the parent ticket for this plan.
We need probably a proposal making sure we have the plan right before going to implement it.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
FWIW: #25260 (moved) has some good historical context for options on how to integrate Tor Launcher into tor-browser. We can benefit from the work done there.
Keep tor-launcher.git as a separate repository so that other projects such as TorBirdy can continue to package the code as an XPCOM extension.
Fix other incompatibilities with the Firefox ESR68 codebase as we find them. For example, support for XUL overlays has been removed by Mozilla, so we will instead need to preprocess some of the Tor Launcher source files in order to include some shared XUL.
For 1. above we will need decide on the best way to pull the Tor Launcher code into Tor Browser. We could use a git submodule and integrate tightly with the browser build process, or we could "post process" browser/omni.ja to add the necessary Tor Launcher pieces.
A related goal will be to keep the Tor Launcher files together as much as possible within the browser package; this will make it easier for developers to drop in updated Tor Launcher files for testing (but it will never again be as easy as just copying over an .xpi file). Within browser/omni.ja, we will probably need to place files under these subdirectories:
defaults/preferences/
chrome/torlauncher/
components/torlauncher/
and we will need to ensure that the following manifest files are updated to register the Tor Launcher pieces:
chrome/chrome.manifest
components/components.manifest
We will also need to decide whether it is worthwhile to rename the preferences, e.g., extensions.torlauncher.loglevel could be renamed to torlauncher.loglevel
Something that came to mind: we should think what to do with the Tor Network Settings... as the onion button is likely to go away during the Torbutton integration.
We also need to update the proposal to account for feedback we received from Tails as well as a couple of other things we learned; we will do that soon. For localization, including all of the completed translations seems to work fine. Also, we ended up keeping the pkg-prepare target in the Tor Launcher Makefile because it may be useful for TorBirdy or other projects (that Makefile is no longer used by the tor-browser-build process).
Trac: Keywords: TorBrowserTeam201902 deleted, TorBrowserTeam201902R added Status: new to needs_review
Nice! Have you by chance tried testing the mechanism you are using for integrating Tor Launcher into the browser in, say, some recent-ish mozilla-central build? It might be worth it in order to figure out whether we could do more work already now in case there are unanticipated problems with our migration plan for esr68.
Trac: Description: We need to move away from our XPCOM extensions, Tor Launcher being one of them. As for Tor Browser it might be hard/impossible. if we tried to reimplement everything Tor Launcher does with the WebExtensions API. Instead we plan to integrate it tighter into the browser itself making use of it's capabilities.
This ticket is the parent ticket for this plan.
We need probably a proposal making sure we have the plan right before going to implement it.
to
We need to move away from our XPCOM extensions, Tor Launcher being one of them. As for Tor Browser it might be hard/impossible, if we tried to reimplement everything Tor Launcher does with the WebExtensions API. Instead we plan to integrate it tighter into the browser itself making use of its capabilities.
This ticket is the parent ticket for this plan.
We need probably a proposal making sure we have the plan right before going to implement it.
Nice! Have you by chance tried testing the mechanism you are using for integrating Tor Launcher into the browser in, say, some recent-ish mozilla-central build? It might be worth it in order to figure out whether we could do more work already now in case there are unanticipated problems with our migration plan for esr68.
We did not try the build integration, but in early January we performed an experiment in which we manually embedded Tor Launcher inside a nightly build of Firefox 66 (that is, we hacked browser/omni.ja). I do not remember everything about that experiment, but the general integration approach was successful (although #29197 (moved) needs to be fixed for Tor Launcher functionality to work fully in newer Firefox builds).
Please let us know if you want Kathy and me to do a new, more thorough experiment.
Nice! Have you by chance tried testing the mechanism you are using for integrating Tor Launcher into the browser in, say, some recent-ish mozilla-central build? It might be worth it in order to figure out whether we could do more work already now in case there are unanticipated problems with our migration plan for esr68.
We did not try the build integration, but in early January we performed an experiment in which we manually embedded Tor Launcher inside a nightly build of Firefox 66 (that is, we hacked browser/omni.ja). I do not remember everything about that experiment, but the general integration approach was successful (although #29197 (moved) needs to be fixed for Tor Launcher functionality to work fully in newer Firefox builds).
Please let us know if you want Kathy and me to do a new, more thorough experiment.