Mike made a comment here: https://trac.torproject.org/projects/tor/ticket/6457#comment:9 that caused Kathy and me to do some more thinking about the TBB package structure and how we can simplify the patches required for #4234 (Use Firefox updater). The purpose of this message is to get input from everyone.
The question: Should we change TBB so it it structured on disk just like Firefox? In other words, can we pull the Firefox ("Browser") directory up to the top of our package? This would provide several advantages:
+ The patches for #4234 (Use Firefox updater) would be much smaller, which means maintenance would be easier, Mozilla would be more likely to accept the small patches we would be left with, and so on. This would be a *huge* win and it is the main reason we are asking this question.
+ Bugs such as #6457 (Mac dock icon problems) would disappear.
+ The TBB package would look less like a bundle and more like a browser that is based on Firefox.
There are also some challenges that stopped us from doing this last fall. The RelativeLink wrappers perform some useful functions and it may be difficult to eliminate them entirely. Our current thinking is that we could adopt a slightly different approach for each operating system:
- On Mac OS, Kathy and I think we can keep the wrapper script but eliminate the nested .app structure. This should solve the dock icon problems. The main reason we need the wrapper is to ensure that -no-remote is passed to firefox (we do not want someone to try to open TBB and have a new Firefox window open up instead, just because they happen to have Firefox running). Even if we don't make changes for Linux and Windows, it probably makes sense to do so for Mac OS since the package innards are mostly hidden from users.
- On Linux, we can keep the wrapper script but move it down into the Firefox ("Browser") directory. To keep end-users from being overwhelmed by all of the files that are in the firefox directory directory, we could provide a symlink at the top and use a structure that looks like this: tor_browser_en_US/ start-tor-browser@ (symlink to Browser/start-tor-browser) Browser/ (Firefox directory) Browser/start-tor-browser (wrapper script) Browser/Tor/ (new parent for Data, Docs, Tor dirs.) Browser/firefox (executable) ... Note that the Firefox updater would not be able to touch anything above the Browser directory, so we can't put anything above that point that we will EVER need to update. But we can probably get away with using one symlink.
- On Windows, like Linux, we have the problem of not wanting to overwhelm end-users by showing them a folder with a bunch of files in it and hoping they will locate and open the one named firefox.exe (a challenging task, given that they just installed a package named "Tor Browser"). But we could use a structure similar to what I proposed above for Linux; our Windows installer could create a shortcut that includes -no-remote, e.g., Tor Browser/ Start Tor Browser.lnk (installer-generated shortcut) Browser/ (Firefox directory) Browser/Tor/ (new parent for Data, Docs, Tor dirs.) Browser/firefox.exe ... If, someday, we provide a .zip package on Windows, users of it will need to create their own shortcut or they will need to find and open firefox.exe (but that means they may not neglect to include the -no-remote flag).
A side note is that we do not need -no-remote if we are willing to change the Tor Browser to look like a different application (compare to Firefox), i.e., register a different window class on Windows, use a different creator code on Mac OS, etc. But there may be reasons we do not want to be different from Firefox in that way.
Opinions on all of the above? Pitfalls? This change will be disruptive to developers, support people, and end-users but the long term benefits might make it worth doing.