[tbb-dev] structure TBB more like Firefox?

[Mike Perry]

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.

-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20140324/3d1e1c3d/attachment-0001.sig>