Woah this email got long. How Firefox considers whether to pass off to an
existing instance of Firefox or continue launching a new one turns out to
be more complex than you might expect. I'm mostly interested in making
folks aware of and giving feedback on how this works after I've changed
some things so feel free to jump down there. But I figured some folks might
find some context in how things work currently. For that, read on!
One of the goals of pushing to a profile-per-install model for Firefox is
allowing users to run different versions of Firefox side-by-side without
the additional hassle of editing shortcut files or running from the command
line. This has meant changing the "remoting" code, which searches for
existing instances of Firefox and passes command line arguments to them
instead of starting up normally. I landed the changes to this a couple of
days ago and I thought it was worthwhile explaining what has changed since
it might not be exactly what you expect. And if that is the case figure out
whether it makes sense to make any changes.
*So first, a quick recap of what remoting has done in the past, because it
varies from platform to platform...*
OSX is the easy case. Firefox doesn't handle remoting at all. OSX does it
all, assuming you are running Firefox by running an app bundle or a dock
icon. OSX sees that an existing Firefox is running and just sends it a
message, a new Firefox instance doesn't even start. I've made no changes
Windows is the slightly more complex case. When run Firefox attempts to
find an already running Firefox. If one exists it passes its command line
off to it and quits. The -no-remote command line argument is a way to
bypass this behaviour, running with it will stop the new Firefox from
attempting to find an existing instance or becoming and instance that can
be found by other instances. Basically there can only be one Firefox open
that can be found by future invocations. The -new-instance command line
argument is parsed on Windows ... and then ignored.
Finally there is Linux. The more exciting case. Unless -no-remote or
-new-instance are passed on startup linux will search for an existing
version of Firefox based on a few criteria .. which varies a little
depending on whether we're using dbus remoting or X remoting. We use X
remoting if we are using X11 windows, and dbus if not (and dbus is
supported). In both cases on startup Firefox attempts to find an existing
instance of Firefox with the same remoting name (or you can provide a
different remoting name with -a on the command line). dev-edition has one
remoting name, all other versions of firefox have a different one. If there
is more than one .. which one wins seems undefined. You can additionally
pass "-P <profile name>" in which case Firefox will only select an existing
instance running the named profile. On X remoting there are a few extras.
Passing "-a any" on the command line will find any running Firefox
regardless of remoting name. Passing "-u <username>" will consider
Firefoxen run by the given user (otherwise it only looks at those run by
the current user). -no-remote means FIrefox doesn't register itself to be
found by future instances. -no-remote or -new-instance means we don't look
for existing instances on startup.
So that's all rather complicated. To make matters more fun the linux and
windows implementations are handled by totally separate code running at
different times during startup. The two key problems here were that windows
completely didn't support more than one instance running, unless all but
one were -no-remote, and linux was horribly complex and again unless you
ran with command line arguments didn't support more than one Firefox at a
time. We wanted something that allowed running Firefox release and Firefox
beta and Firefox nightly with no special arguments at the same time.
So I have done three things. Removed support for some of the things Linux
supported. Made the code a lot more shared between windows and linux so
things happen at the same time regardless of platform and both platform
have what should be identical behaviours. Changed the order of when some
What did I remove? Support for remoting to a different remoting name and a
different user. Both seem unlikely to be useful for normal use cases, the
latter frankly feels like a security risk.
*How does it all work now?*
OSX hasn't changed, maybe we'll want to do some changes here, but for now
it already allows running different versions of Firefox so long as they are
using different profiles, which is the default. So for the rest of this
assume I'm talking about Linux (dbus or x11) and Windows. They all should
behave the same.
The new remoting does everything based on profile. When starting Firefox we
do normal profile selection, which includes considering any -P and
--profile command line arguments. Once we've selected a profile we attempt
to find an existing Firefox instance using that profile. If one is found we
send it our command line arguments and quit. If not continue start up.
Since different installs of Firefox use different profiles by default this
generally means that running Beta would pass off to an existing Beta. Same
for other installs. It also means if you do "firefox -P foo -url
" we'll open that url in profile Foo, either by using an
existing Firefox using profile Foo or by starting with profile Foo.
-no-remote and -new-instance still exist. Right now they do the same thing,
they make Firefox not look for existing instances and not listen for
remoting from future instances. They are pretty pointless now though, the
only case where they would have an effect is when a second instance is
trying to use a profile that is already used by an existing instance ... at
which point we'll show the profile locked dialog on startup and refuse to
The most visible side-effect that folks have started seeing from this
change is caused by waiting for profile selection to occur before
attempting to remote. If Firefox is configured to always show the profile
manager on startup then attempts to open links from outside apps will cause
the profile manager to show, because that is what selects the profile.
Selecting the profile of an already running Firefox from the UI will then
remote to that Firefox (barring a bug that should be fixed in the next
nightly), but this is a change in behaviour and honestly not one I'd
spotted before landing. In some ways the new behaviour kinda makes sense
(if there wasn't already a Firefox running you'd get the profile UI
previously too) but I can see how it is confusing too so it might be worth
considering changing something here, we'd just have to figure out what
profile we should use in this case.
The other thing that might be confusing is that the version or install of
Firefox you try to launch doesn't affect which version or install of
Firefox you might end up remoting to. This has always been the case on
Windows and normally the case on Linux, unless you pass an extra command
line argument though so I'm not too concerned here.
Hopefully this all makes sense. I'd like to hear if folks think that this
is the wrong way to support this and if you spot any issues with it that I