Bug #7943

The Tor Browser cannot use -profile together with -app

Added by anonym 2014-09-24 07:32:53 . Updated 2016-02-18 20:44:13 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Target version:
Tails_2.0.1
Start date:
2014-09-24
Due date:
% Done:

100%

Feature Branch:
bugfix/7943-simplify-tor-launcher-profile-path-workaround
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Browser
Deliverable for:

Description

When running a XUL application with -app, the -profile argument is ignored, and the default profile path is used. After the TBB migration that means the profile path becomes relative to the application.ini file thanks to the Tor Browser patches. This forces us to use a really ugly workaround to be able to run the Tor Launcher as a standalone application with a sane path for the profile (see config/chroot_local-includes/usr/bin/tor-launcher).

A good question is if the Tor Browser patches (e.g. the one that alters the default profile path) breaks this, of if -profile simply isn’t supported together with -app in upstream Firefox. If the former is true we should fix this, otherwise we can try to “improve” the Tor Browser’s patch so an environment variable can override the profile path, or similar.

Subtasks

Related issues

Blocked by Tails - Bug #11097: Most browser test suite scenarios fail on ISO images built from the devel branch Resolved 2016-02-09

History

#1 Updated by intrigeri 2014-10-31 17:43:54

  • Feature Branch deleted (feature/tor-browser-bundle)

#2 Updated by anonym 2015-09-11 09:02:02

I had a look at this: https://developer.mozilla.org/en/docs/XUL_Application_Packaging and saw the following explanation of the Profile option in applications.ini for (standalone) XUL applications, like our Tor Launcher:

> Profile
> Specifies the path to use for the application’s profile, based within the user’s application data directory
> OPTIONAL
> Example: Profile=MyAppData

So it seems that for XUL applications there’s an inherent limitation that the profile must be located within the application’s data directory. That seems arbitrary and not very multi-user-friendly. Hmm. Still I am inferring stuff from a guess here.

#3 Updated by anonym 2015-09-11 15:50:25

  • Status changed from Confirmed to In Progress

Applied in changeset commit:42372cd7fc82a771d8ecec13d8b7b14fafb017b5.

#4 Updated by anonym 2015-09-13 06:41:41

  • Assignee deleted (anonym)
  • % Done changed from 0 to 50
  • QA Check set to Ready for QA
  • Feature Branch set to bugfix/7943-simplify-tor-launcher-profile-path-workaround

Err, -profile works together with -app if but after it. Argh. Fix pushed!

Note that quite a bit of the branch is a bit unrelated (but necessary cleanups/fixes in the surrounding areas), but it’s mostly moving code around and fixing obvious mistakes so it shouldn’t be hard to review and test. I hope this is ok, otherwise let me know and I split the branch — I was just hoping to avoid some ticket overhead etc.

#5 Updated by intrigeri 2015-09-15 02:37:31

  • Target version set to Tails_1.7

#6 Updated by anonym 2015-11-06 08:04:51

  • Assignee set to anonym
  • QA Check changed from Ready for QA to Dev Needed

Broken according to automated tests done by jenkins.

#7 Updated by anonym 2015-11-23 04:38:51

  • Target version changed from Tails_1.7 to Tails_1.8

#8 Updated by intrigeri 2015-12-05 14:02:16

  • Target version changed from Tails_1.8 to Tails_2.2

Postponing to after January, since times will be crazy until then.

#9 Updated by anonym 2016-02-10 14:13:07

  • Assignee changed from anonym to intrigeri
  • QA Check changed from Dev Needed to Ready for QA

I’ve force pushed a rebased (on current devel) version of the branch — the merge conflict was huge and confusing, and I found it easier to deal with it on a per commit basis. The commits also take into account various new functionality and other changes, e.g. @vm ⇒ $vm, the :libs option for execute().

#10 Updated by anonym 2016-02-10 14:40:23

I’ve only run torified_bridges.feature successfully — the other .feature:s are currently broken due to Bug #11097.

#11 Updated by intrigeri 2016-02-10 15:03:41

  • Assignee changed from intrigeri to anonym

Code review passes at commit:2fc6d139c647b12199a88de8ccf7b41915b7211e.

> I’ve only run torified_bridges.feature successfully — the other .feature:s are currently broken due to Bug #11097.

OK, please reassign to me once I can test & merge it, then.

#12 Updated by intrigeri 2016-02-10 15:03:45

  • blocked by Bug #11097: Most browser test suite scenarios fail on ISO images built from the devel branch added

#13 Updated by intrigeri 2016-02-11 12:26:21

  • Assignee changed from anonym to intrigeri

#14 Updated by intrigeri 2016-02-11 14:20:15

  • Status changed from In Progress to Fix committed
  • % Done changed from 50 to 100

Applied in changeset commit:614c63ea14fa5d9ee939eec013f8448fbb187f37.

#15 Updated by intrigeri 2016-02-11 14:25:15

  • Assignee deleted (intrigeri)
  • QA Check changed from Ready for QA to Pass

I’ve run features/torified_browsing.feature features/tor_bridges.feature features/unsafe_browser.feature features/i2p.feature features/checks.feature features/localization.feature features/tor_enforcement.feature on an ISO based on stable, with the branches for Bug #11097, Bug #7943 and Bug #9896 merged in. I’m happy with the results. The only failures I’ve seen were:

  • typical robustness issues, and manual inspection of the screenshots reveals that Tails works fine, but the test suite doesn’t manage to realize it
  • Bug #9896#note-21 that should be very easy to fix, presumably

So I feel I can vouch, without being too scared, for merging these 3 branches at once into stable.

#16 Updated by anonym 2016-02-11 15:53:37

intrigeri wrote:
> I’ve run features/torified_browsing.feature features/tor_bridges.feature features/unsafe_browser.feature features/i2p.feature features/checks.feature features/localization.feature features/tor_enforcement.feature on an ISO based on stable, with the branches for Bug #11097, Bug #7943 and Bug #9896 merged in. I’m happy with the results. The only failures I’ve seen were:
>
> * typical robustness issues, and manual inspection of the screenshots reveals that Tails works fine, but the test suite doesn’t manage to realize it
> * Bug #9896#note-21 that should be very easy to fix, presumably
>
> So I feel I can vouch, without being too scared, for merging these 3 branches at once into stable.

Ok. I’ve pushed and verified my fix to the issue you mentioned above, so I’ve now proceeded to merge these three branches into stable, and stable into devel.

#17 Updated by intrigeri 2016-02-12 13:18:15

  • Target version changed from Tails_2.2 to Tails_2.0.1

#18 Updated by intrigeri 2016-02-18 20:44:13

  • Status changed from Fix committed to Resolved