Running different instances of Firefox side-by-side

Dave Townsend dtownsend at mozilla.com
Thu Mar 14 16:12:11 UTC 2019


Yes sorry, corrected that.

On Thu, Mar 14, 2019 at 6:19 AM Marco Castelluccio <
mcastelluccio at mozilla.com> 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:
> >
> > 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.
> >
> > On Mon, Mar 11, 2019 at 11:35 AM Dave Townsend <dtownsend at mozilla.com>
> > 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
> >> 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.
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20190314/e104ad35/attachment.html>


More information about the firefox-dev mailing list