Running different instances of Firefox side-by-side

[Dave Townsend]

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
www.google.com" 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.

[Michael Cooper]

On Mon, Mar 11, 2019 at 11:35 AM Dave Townsend <dtow...@mozilla.com>
wrote:

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Michael Cooper]

While composing this, I accidentally sent a blank message. Sorry about that.

Thanks for writing this up Dave, it is really interesting to know how this
is changing. It also explains what I thought was a bug the last few days. I
have the profile manager enabled for every startup. In the past, getting
the "choose a profile" modal on Linux always meant that remoting had failed
for some reason. So when I started getting it when clicking links in
external apps, I assumed that is what happened, closed the profile chooser,
and copy/pasted the link over. In other words, I was in fact confused by
this new behavior, since it looked similar to old buggy behavior.

Now that I know what's going on, it makes a lot of sense, and in fact I
really like being able to choose a profile to start in. On the other hand,
since it looks very similar to a buggy behavior, it was pretty easy to
assume it was bugged. Perhaps the profile manager could explain that it
will try and find an existing profile and remote in to it?

[Randell Jesup]

>-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.

[snip]

>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.

-no-remote is still quite useful when debugging; if I build in one of my
dev repos, and then ./firefox -P test -no-remote, it will warn me if I
have another instance using that profile (quite possibly from a
different repo/directory) instead of silents loading it in that other
instance - which can be very confusing if you're trying to test a fix.
("I *swear* I made that change; why didn't it take?")

>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.

Thanks for doing this; the current system kinda fell out of various
needs mostly around 20+ years ago and hadn't been revisted since then
really.

--
Randell Jesup, Mozilla Corp
remove "news" for personal email

[Dave Townsend]

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:

https://bugzilla.mozilla.org/show_bug.cgi?id=1535021 Don't show the profile
manager when the default profile was selected and an existing instance is
running.
https://bugzilla.mozilla.org/show_bug.cgi?id=1535144 Return -new-instance
to its previous behaviour.

> -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.
>

[Marco Castelluccio]

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:

[Dave Townsend]

Yes sorry, corrected that.