Wandering Thoughts archives

How I run two Firefoxes at once and still have remote control

Given how Firefox remote control works on Unix, you might wonder how I routinely run two separate copies of Firefox and still have my remote control environment work reliably enough that I haven't pitched one of the copies out the window long ago.

In theory, the answer is Firefox's -no-remote argument. In practice this doesn't work quite the way you want it to. The problem is that a Firefox instance run with -no-remote will still register itself as a valid target for remote control, alongside your main browser. You can start your second Firefox without problems, but from then onwards your remote control attempts may go to it, not to your main browser where you (probably) want them.

So I cheat. One of my customizations is that I changed the source code to rename the X properties that my main browser uses for remote control, precisely so that I could run it alongside a normal Firefox without either clashing.

This is obviously only an option for people who compile Firefox from source, but you don't have to go that far; you can just edit the binary. There are two binary files that you need to edit, mozilla-xremote-client and libxul.so, and in each you need to change the following strings:

_MOZILLA_VERSION _MOZILLA_LOCK _MOZILLA_COMMAND _MOZILLA_RESPONSE _MOZILLA_USER _MOZILLA_PROFILE _MOZILLA_PROGRAM _MOZILLA_COMMANDLINE

It's easy to find the right place to change, because the strings are all embedded together in the binary. Obviously their lengths need to stay the same; my traditional change is to change the _MOZILLA bit to _MEZILLA.

(I use GNU Emacs in overwrite mode for all of my binary editing needs, but there are probably better alternatives.)

If you prefer to not make binary edits to Firefox, it turns out that there's another way to do it; Firefox's remote control code checks to see if the program, the user, and the profile match before sending a command off to the remote control target. Thus the simple way to avoid all of the remote control problems is to run your testing Firefox with a non-default profile name.

(Manipulating the user name is possible and perhaps easier; you can just set $LOGNAME in your cover script. However, I don't know if this has other effects on Firefox or things that you may start from inside it.)

How I set up my isolated testing Firefox environment

Yesterday I covered how I actually run two web browsers, one for my real browsing and one for various sorts of testing and isolated browsing. That raises a question: how do you set up something like that?

In theory, you could just use an alternate Firefox profile (with a script to start your test Firefox with the right magic arguments). In practice I have never trusted Firefox's profile system that much, partly because in the past I spent some time testing out potentially buggy development builds. So I have always used the bigger hammer of changing my $HOME.

On Unix, Firefox (and Mozilla before it) has always respected $HOME (if set), instead of doing something unsocial like looking up the user's home directory in the passwd file. Thus the simplest way of getting a completely independent testing environment is changing $HOME to point to somewhere convenient. For my general testing Firefox environment, I use a persistent directory in ~/tmp (so that I can set Firefox preferences and have them stick); for scratch testing, you can just set $HOME to, say, /tmp/ffox-test, make the directory, run Firefox, and delete the directory afterwards.

You will also want to start the testing Firefox with the -no-remote command line argument (see here); otherwise your testing instance may just send things to your main browsing session. I deal with this in a somewhat eccentric way, so you may need to experiment with the best way of making everything work given Firefox's insistence on doing various bits of remote control.

(I put all of this stuff in a script that I call 'foxnative'. Remember to do 'export HOME' after setting $HOME, just to be sure.)

At one point I needed some extra steps to make sound work with PulseAudio, because it required some magic files in your home directory in order to connect to the PulseAudio server and it too respects $HOME. Back when I ran into this, I wound up using rsync to copy ~/.pulse to the new $HOME; however, that appears to be unnecessary now in current versions of Fedora.

(This shows one quiet little hazard of scripts, which is that they can automate something that turns into folklore over time while you're not paying attention.)