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. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform