Opens a non-Tor Firefox window, if Firefox is already running

[pde]

Since the last update (nominally 0.1.6-1 -> 0.1.7-1, but I'm building from git), torbrowser-launcher has stopped working if Firefox is already running. Instead, it just opens a new window from the currently running FF profile.

[micahflee]

Sorry about the stupid late response. I'm testing in Debian and I can't reproduce. I have Iceweasel open, and when I open Tor Browser Launcher it opens a new Tor Browser window. I also have Tor Browser set as my default browser. When I close the Tor Browser window and click a link in some other program, it opens the link in a new Tor Browser and ignores Iceweasel.

Can you give more details on how to reproduce?

[pde]

To reproduce:

1. Download an upstream Mozilla build of Firefox
2. Run it, select a profile
3. Run torbrowser-launcher. It will open a window in the currently-running profile.

Like you, I can't reproduce this with iceweasel (but I generally don't run iceweasel, because it's based on ESR rather than the latest Firefox).

[jperryhouts]

I can reproduce this bug in Ubuntu with Firefox installed from the default repository.

[grrrrr]

I have just upgraded to 0.1.8-1 and the following now happens

1. If regular default firefox is already running but not TBB, running torbrowser-launcher just opens a new firefox window

2. If TBB is already running but not regular default firefox, clicking the firefox launcher opens a new Tor Browser window.

With 0.1.7-1 and below, both browser launchers acted independently.

[micahflee]

I don't use Firefox on a regular basis, so haven't been noticing this one. But with the 0.1.8, this is an urgent issue to fix. Working on it.

[micahflee]

The problem is boils down to the -allow-remote parameter when launching Tor Browser: https://github.com/micahflee/torbrowser-launcher/blob/master/torbrowser_launcher/launcher.py#L637

Basically, firefox has a command line argument, -no-remote, that forces firefox to open in a new process, and prevents outside proccesses from communicating with it (e.g. opening new tabs). This is the default case with Tor Browser.

If you want to be able to pass URLs into an already-open Tor Browser process, then you must run start-tor-browser with the -allow-remote flag. What this specifically does is checks to see if there's another firefox open, if there is it passes a URL, if there isn't it opens a new Tor Browser with that URL.

But if you have a non-Tor Browser firefox process open in the background, and you run ./start-tor-browser -no-remote, it will notice that firefox is already open and open the URL in that browser, not realizing that firefox and Tor Browser are separate browsers. In fact, if firefox is closed and you open a URL with Tor Browser Launcher, and then try opening firefox again like normal, it will open a new Tor Browser tab.

The reason that this issue doesn't affect Debian when Iceweasel is open is, I'm pretty sure, because the Iceweasel process is called iceweasel and not firefox, so it doesn't get confused.

I'm trying to figure out how to deal with this. I've already tried renaming tor-browser_en-US/Browser/firefox to tor-browser_en-US/Browser/torbrowser and patching start-tor-browser, but no dice. It looks like start-tor-browser already passes --class 'Tor Browser' into the firefox command that it runs, but this doesn't seem to help.

I'm worried that without an upstream patch to the firefox that comes with Tor Browser, it might not be possible to resolve this issue without removing the capability to open URLs in Tor Browser.

A workaround, of course, is to stop using Firefox and switch to Chromium or something as your non-Tor browser.

[micahflee]

Also, this has been an issue since I introduced the ability to pass URLs into Tor Browser. It was just less noticable due to another bug. If you opened Tor Browser for the first time by clicking a link, then you could continue to click more links to open new tabs. However if you opened Tor Browser the first time by just opening it, it wouldn't open with -allow-remote, and therefore it couldn't pass new URLs into the running process.

This commit de13483 fixed it. But also made it so when you open Tor Browser at all, if firefox is open in the background, it instead opens a new tab in firefox.

[micahflee]

So it seems to be that the choices are:

• Remove the ability to pass URLs into Tor Browser
• Add a new setting that toggles whether -allow-remote is passed into start-tor-browser or not -- if it is, you can use Tor Browser as your default browser as long you don't use Firefox at the same time
• Change how -allow-remote works in TBB upstream, to prevent it from ever using an existing Firefox

Anything else?

[grrrrr]

@micahflee the latest update (0.1.9-1) has certainly work around the issue if not fixed it and I can now use both browsers independently.

[micahflee]

Yes, it should be 100% worked around at this point. But it's still a shame that you can't set Tor Browser as your default browser and use Firefox at the same time. I plan on opening an upstream TBB bug about this (when you run start-tor-browser -allow-remote example.com it really should always open this in Tor Browser, and never in Firefox). Hopefully in the future I'll be able to remove that setting I just added, and the default browser thing will just work whether or not you use Firefox.

[MeisterP]

The reason that this issue doesn't affect Debian when Iceweasel is open is, I'm pretty sure, because the Iceweasel process is called iceweasel and not firefox, so it doesn't get confused.

To rename the firefox binary to torbrowser, upstream would need to pass --with-app-name=torbrowser and --with-app-basename=torbrowser to the firefox configure options.

[micahflee]

In start-tor-browser line 300 looks like this:

TOR_CONTROL_PASSWD=${TOR_CONTROL_PASSWD} ./firefox  --class "Tor Browser" \
    -profile TorBrowser/Data/Browser/profile.default "${@}"
exitcode="$?"

If I copy Browser/firefox into Browser/torbrowser and then modify that part of start-tor-browser to be this instead:

TOR_CONTROL_PASSWD=${TOR_CONTROL_PASSWD} ./torbrowser --with-app-name=torbrowser --with-app-basename=torbrowser --class "Tor Browser" \
    -profile TorBrowser/Data/Browser/profile.default "${@}"
exitcode="$?"

It still appears to act the same way. If Firefox is open in the background and I run ./start-tor-browser -allow-remote it still opens a new Firefox tab, rather than opening Tor Browser.

I haven't actually confirmed that the reason it opens a Firefox tab is because of the process name -- there could be something different there.

[MeisterP]

~ % which torbrowser
/usr/bin/torbrowser
~ % torbrowser -allow-remote

and in another terminal

~ % which firefox
/usr/bin/firefox
~ % firefox

torbrowser -allow-remote example.com opens a new tab in torbrowser and firefox example.com opens a new tab in firefox

this is a torbrowser built on gentoo with some additional options passed to configure: https://github.com/MeisterP/torbrowser-overlay/blob/master/www-client/torbrowser/torbrowser-31.4.0.ebuild#L169

Edit: --with-app-name=torbrowser and --with-app-basename=torbrowser are configure options used at build time and not command line parameters.

[micahflee]

In the TBB 4.5 they updated the star-tor-browser script, which actually removed support for passing -allow-remote in anyway. So I've removed support for opening external links, which sort of makes this issue go away. #176