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? On Mon, Mar 11, 2019 at 12:19 PM Michael Cooper <mcoo...@mozilla.com> wrote: > > > On Mon, Mar 11, 2019 at 11:35 AM Dave Townsend <dtowns...@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. >> _______________________________________________ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform >> > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
