Dissecting Firefox's -no-remote option

Starting multiple instances of Firefox is something I've done countless times, in order to test different versions and use different profiles. In order to do so I use the handy-dandy -no-remote option. However, the documentation on -no-remote is a little sparse. So let's looks at what the option really does, and how it came to be!

A history of remote control

'Remote' refers to remote commands, as in, remote control and command of Firefox. The remote control functionality traces itself to the ye olde days of Firefox's code: archives show it in fact came from the time of Netscape. This option was Unix, X-Window based platforms only, as you can see here and here, and allowed you to specify various options to control an already running browser from the command line.

The above is important to understand for why we have the -no-remote name: -remote was used to instruct an already running browser. Indeed, it explicitly wouldn't work without an already running browser to communicate with. So in this context, remote came to mean something akin to "talk to the already running browser".

The -remote option was removed in version 39. But, it's influence lives on in both code and terminology.

The birth of -no-remote

Nowadays, you can execute Firefox again to open a new window or tab in your already running instance. In the old days, this same behaviour could be achieved using -remote. Even on platforms like Windows, where the -remote option didn't function, the 'remote' terminology is used to refer to connecting to an existing instance to open new windows or tabs.

Thus it came to be that if you wanted to not talk to an existing instance, if you wanted to open a new instance of the browser, you would specify the environment variable MOZ_NO_REMOTE. The -no-remote switch, which essentially does the same thing as setting the environment var, was later born via this bug.

Here already the term 'no-remote' means "don't talk to an existing Firefox, start a new instance". To be clear: on platforms where the -remote option doesn't work, -no-remote is still used to mean don't connect to a running instance.

The changing implementation of -no-remote

At the stage -no-remote was implemented, the -remote option still existed. And while -no-remote meant you wouldn't talk to an existing browser, it didn't stop new instances talking to your -no-remote instance after it had started.

This changed later, and -no-remote was made to also block connections sent to instances started with -no-remote. See this bug for that change. While some found this behaviour intuitive, others did not, which resulted in requests for the old behaviour to return under a new switch: -new-instance. This was done here.

The strange life of -new-instance

-new-instance feels like a bit of an awkward option. It does not work on Windows, as noted here, and at face value it's difficult to tell what it does differently than -no-remote. Though if you were just going off the names, -new-instance is a lot more self-explanatory.

I typically see people suggest strictly using -no-remote over -new-instance. This is sensible, as -no-remote works on all platforms and the subtle differences between the two are not important when you just want a new instance. But it's a shame that the more descriptive name is relegated to obscurity.

And here we are

So, now we have:

1. -no-remote, which prevents the new instance sending or receiving remote commands.
2. -new-instance, which prevents the new instance sending remote commands, but it can still receive commands.
3. The original -remote is gone, but its influence lives on.

If you're interested in the actual code changes that took place, the bugs here give a place to start. When trawling the Mozilla code base, the Mercurial log keyword switch is useful for changesets relating to specific bugs. For example if I want to find changesets relating to bug 650078 I can use hg log -k 650078.

Updates and clarifications

• Firefox will accept both single dash -no-remote and double dash --no-remote. Different docs may refer to either form, and both do the same thing.
• Since I first wrote this, there has been a reworking of the platform specific handling of -no-remote. There's a great write up on the dev-platform mailing list for those interested. This is another example of how the functionality of -no-remote shifts over time.

Feel free to reach out to me if you have questions or corrections.