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.
Mark Smith:
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.
Right. I think this reason alone is enough to reorganize.
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 ...
These three sets of changes sound reasonable.
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).
I don't think we're going back to .zip anytime soon. However, we do want to ensure that the NSIS scripts are robust enough to allow us to generate this link without any code (and hope that we never have to change the filename it points to).
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.
Yeah. I think we want to also rethink remoting. For the short term, we can hardcode it to default to disabled, right? In the longer term, we may want to separate the Tor Browser window names so that remoting actually works and does not interfere with Firefox (for https://trac.torproject.org/projects/tor/ticket/5203).
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.
We have reorganized the bundles before for 3.x. I am not sure how much havoc that caused for support. That would be useful to know.
I think if we call this new reorganized, self-updating bundle version 4.0, users might get the hint that they can't just extract/copy it over their old TBB directory (and we could tell them this on the blog+FAQ+help docs), but I could be way off in terms of how much that will actually matter.
On 3/24/14, 4:21 PM, Mike Perry wrote:
I don't think we're going back to .zip anytime soon. However, we do want to ensure that the NSIS scripts are robust enough to allow us to generate this link without any code (and hope that we never have to change the filename it points to).
We will experiment to make sure NSIS can create the shortcut we need.
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.
Yeah. I think we want to also rethink remoting. For the short term, we can hardcode it to default to disabled, right?
Yes, although Kathy and I are a little worried that doing so may break things like opening links from other applications.
In the longer term, we may want to separate the Tor Browser window names so that remoting actually works and does not interfere with Firefox (for https://trac.torproject.org/projects/tor/ticket/5203).
Agreed.
We have reorganized the bundles before for 3.x. I am not sure how much havoc that caused for support. That would be useful to know.
I think if we call this new reorganized, self-updating bundle version 4.0, users might get the hint that they can't just extract/copy it over their old TBB directory (and we could tell them this on the blog+FAQ+help docs), but I could be way off in terms of how much that will actually matter.
Labeling it "4.0" would probably help a little.
As a next step, Kathy and I will experiment with a reorganized bundle on Mac OS. If that goes well, we will look at Linux and Windows.
-
Mark Smith -
Mike Perry