[tbb-dev] structure TBB more like Firefox?

[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.

+ 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
Pearl Crescent
http://pearlcrescent.com/