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: legacy/trac#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 legacy/trac#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 legacy/trac#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.
b7e7058359b402e9f37e27a86b99b68702189cdb - looks good
80cedf677bb43d10c6b37902ca22af7650752bf0 just one white space between "locale" and "torlauncher" (in +% locale torlauncher en-US %locale/en-US/) as used for the other locales and no "/" at the end of locale/en-US/ as done with the other locales, otherwise this looks good
2dd09cb68db2b267cd12db7ce542406791fd6ef7 - there are some conflicts with the languages strings (sorry for that), otherwise this looks good
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.
Okay, works for me in a follow-up ticket.
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).
Sounds good.
Trac: Keywords: TorBrowserTeam201905R deleted, TorBrowserTeam201905 added Status: needs_review to needs_revision
b7e7058359b402e9f37e27a86b99b68702189cdb - looks good
80cedf677bb43d10c6b37902ca22af7650752bf0 just one white space between "locale" and "torlauncher" (in +% locale torlauncher en-US %locale/en-US/) as used for the other locales and no "/" at the end of locale/en-US/ as done with the other locales, otherwise this looks good
2dd09cb68db2b267cd12db7ce542406791fd6ef7 - there are some conflicts with the languages strings (sorry for that), otherwise this looks good
We rebased the above changes and fixed the en-US locale issues that you found. We chose to add a trailing / for the non-en-US locales (by modifying import-translations.sh) since the results are more consistent with what Mozilla does. For example, see browser/extensions/pocket/locale/jar.mn. The three new tor-launcher patches are available on the bug28044-02 branch within the brade repo::
https://gitweb.torproject.org/user/brade/tor-launcher.git/log/?h=bug28044-02
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.
Okay, we are done here. The -02 patches look good to me and I merged them to the respective repositories:
The changes in tor-browser-build are in commit 6d94f73dc055c1739a67ffd422f7f5bf29218723 on master.
The changes in tor-browser are in commit 2852840dd1a12dc66e2aa00d97ed73f0761fb1cc on tor-browser-60.6.1esr-9.0-1 (we don't want to have them in 8.5 and thus on the 8.5 branch)
The changes in tor-launcher are in commits ab7e47f4, b46c6039, and 864170b5 on master
Additionally, I bumped the tor-browser branch used for nightlies from now on and the upcoming alpha in tor-browser-build with commit 68d7be6c41aa408c20cb87511efe59e7afa60357 (on master).
Trac: Resolution: N/Ato fixed Status: needs_review to closed