Relocate RelativeLink functionality to Firefox patch

We need to hardcode our home and profile settings from RelativeLink into a Firefox patch so that users still get expected behavior on Mac and Windows if they dock Firefox instead of the RelativeLink exe/containing app.

This will also prevent situations where TBB ends up set as the default browser or link handler, and gets launched to handle a url without RelativeLink.

This is a pretty bad usability bug, because Firefox will end up using the wrong profile if you launch it without RelativeLink right now.

In most cases, this will cause it to fail closed (because the socks proxy won't be listening), but not if the user already has proxy settings overrides for their default profile.

added MikePerry201311R component::firefox patch issues owner::mcs priority::very high resolution::fixed status::closed tbb-3.0-backport tbb-no-uplift tbb-usability type::defect labels

Possibly as part of this, we may want to add code that checks to ensure that the profile we're pointed actually has Torbutton and/or Tor Launcher addons in it, however we probably want to do those checks separately and carefully, or they will break things like Tails.

Trac:
0001-Use-firefox-bin.patch

Did you try using firefox-bin? Please see the attached.

Trac:
Status: new to needs_review

Hrmm, no I didn't. Sounds plausible. Did you try this out?

Also, this probably won't help Windows users, but if it works, we'll just file a new ticket for them.

Trac:
Keywords: N/A deleted, MikePerry201307 added

Yes, I tested and it works for me on OS X 10.8.4. Correct, this doesn't help Windows.

Although, it doesn't address the issue of the default browser / link handler. Just the dock icon.

See also #9091 (closed), which is a related issue/possible dup.

Ok, I merged arlolra's patch because it is an improvement, but we also want to patch Firefox directly to handle the case where Tor Browser is launched to handle urls, and to ensure that if it does end up docked still, it launches with the right profile and homedir.

Trac:
Status: needs_review to needs_revision

Taking ownership of this bug. Kathy Brade and I have a Firefox patch that we will post shortly that modifies the default location for user data (including profiles) to be a directory that is relative to the browser itself. With the patch, docking and launching via desktop URL shortcuts works on both Windows and Mac OS. The launcher programs (e.g., RelativeLink) will not need to pass a profile location; we can just include a profiles.ini file that causes the Tor Browser to use the bundled profile by default. In conjunction with packaging changes planned as part of #9114 (closed), this should be a nice improvement.

Trac:
Cc: ioerror to ioerror, brade
Owner: mikeperry to mcs
Status: needs_revision to assigned

Trac:
9173-profile-location-patch.txt

proposed fix (change Firefox user data location)

Trac:
Keywords: MikePerry201307 deleted, MikePerry201308 added

Trac:
Status: assigned to needs_review

Trac:
Keywords: MikePerry201308 deleted, N/A added

Ok. I have merged this patch. I will also be merging #9114 (closed) soon. If we still need a profiles.ini with both of these merged, can you attach one? (Or one for each platform?)

Trac:
Status: needs_review to needs_information

Replying to mikeperry:

Ok. I have merged this patch. I will also be merging #9114 (closed) soon. If we still need a profiles.ini with both of these merged, can you attach one? (Or one for each platform?)

Thanks for the merge. The 9114 patch includes the profiles.ini files:

Bundle-Data/linux/Data/Browser/profiles.ini Bundle-Data/mac/Data/Browser/profiles.ini Bundle-Data/windows/Data/Browser/profiles.ini

There is one file for each platform because of the structure under Bundle-Data, but I think all three files have the same content.

Oh, one thing was bothering me about this patch. In nsXREDirProvider::AppendProfilePath(), you removed some initializations that made me nervous. I think in all cases where the empty strings were used, IsEmpty() was checked first, but I removed the code that tries to use them anyways just to be safe: https://gitweb.torproject.org/tor-browser.git/commitdiff/f0519e332aa292b6b481dec6f9e6a22640157131

Let me know if you think that is a bad idea for some other reason.

Replying to mikeperry:

Oh, one thing was bothering me about this patch. In nsXREDirProvider::AppendProfilePath(), you removed some initializations that made me nervous. I think in all cases where the empty strings were used, IsEmpty() was checked first, but I removed the code that tries to use them anyways just to be safe: https://gitweb.torproject.org/tor-browser.git/commitdiff/f0519e332aa292b6b481dec6f9e6a22640157131

Let me know if you think that is a bad idea for some other reason.

We left the lines in because the patch was smaller (which may reduce future conflicts when merging with future ESR releases).

Your changes look fine, except I would initialize rv to NS_OK rather than an error. If somehow the profile string was empty, the method would fail on the NS_ENSURE_SUCCESS line.

We committed a follow up fix to address a "profile not found" issue that Mike ran into:

https://gitweb.torproject.org/user/brade/tor-browser.git/commit/0cfceec079329cfedff3baf9f681cfd5860b428d