Running different instances of Firefox side-by-side

Ovidiu Boca ovidiu.boca at
Thu Mar 14 13:47:53 UTC 2019

Hi Marco, 
I think you are looking for bug 1518639 <>. 


> On 14 Mar 2019, at 15:19, Marco Castelluccio <mcastelluccio at> wrote:
> What is the bug where you made the initial changes?
> We should link to the bug the regressions caused by it (I've seen at least a
> couple regressions filed mentioning this post on dev-platform rather than
> the bug where the regression was introduced).
> - Marco.
> Il 13/03/19 22:14, Dave Townsend ha scritto:
>> A quick update here. After hearing some feedback from folks I've filed the
>> following bugs that I should have a patch up for in the next day:
>> Don't show the profile
>> manager when the default profile was selected and an existing instance is
>> running.
>> Return -new-instance
>> to its previous behaviour.
>> On Mon, Mar 11, 2019 at 11:35 AM Dave Townsend <dtownsend at>
>> wrote:
>>> 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
>>> here.
>>> 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
>>> things happen.
>>> 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
>>> startup anyway.
>>> 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
>>> haven't.
> _______________________________________________
> firefox-dev mailing list
> firefox-dev at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the firefox-dev mailing list