<div dir="ltr">Yes sorry, corrected that.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 14, 2019 at 6:19 AM Marco Castelluccio <<a href="mailto:mcastelluccio@mozilla.com">mcastelluccio@mozilla.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What is the bug where you made the initial changes?<br>
We should link to the bug the regressions caused by it (I've seen at least a<br>
couple regressions filed mentioning this post on dev-platform rather than<br>
the bug where the regression was introduced).<br>
<br>
- Marco.<br>
<br>
<br>
Il 13/03/19 22:14, Dave Townsend ha scritto:<br>
> A quick update here. After hearing some feedback from folks I've filed the<br>
> following bugs that I should have a patch up for in the next day:<br>
><br>
> <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1535021" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1535021</a> Don't show the profile<br>
> manager when the default profile was selected and an existing instance is<br>
> running.<br>
> <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1535144" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1535144</a> Return -new-instance<br>
> to its previous behaviour.<br>
><br>
> On Mon, Mar 11, 2019 at 11:35 AM Dave Townsend <<a href="mailto:dtownsend@mozilla.com" target="_blank">dtownsend@mozilla.com</a>><br>
> wrote:<br>
><br>
>> Woah this email got long. How Firefox considers whether to pass off to an<br>
>> existing instance of Firefox or continue launching a new one turns out to<br>
>> be more complex than you might expect. I'm mostly interested in making<br>
>> folks aware of and giving feedback on how this works after I've changed<br>
>> some things so feel free to jump down there. But I figured some folks might<br>
>> find some context in how things work currently. For that, read on!<br>
>><br>
>> One of the goals of pushing to a profile-per-install model for Firefox is<br>
>> allowing users to run different versions of Firefox side-by-side without<br>
>> the additional hassle of editing shortcut files or running from the command<br>
>> line. This has meant changing the "remoting" code, which searches for<br>
>> existing instances of Firefox and passes command line arguments to them<br>
>> instead of starting up normally. I landed the changes to this a couple of<br>
>> days ago and I thought it was worthwhile explaining what has changed since<br>
>> it might not be exactly what you expect. And if that is the case figure out<br>
>> whether it makes sense to make any changes.<br>
>><br>
>> *So first, a quick recap of what remoting has done in the past, because it<br>
>> varies from platform to platform...*<br>
>><br>
>> OSX is the easy case. Firefox doesn't handle remoting at all. OSX does it<br>
>> all, assuming you are running Firefox by running an app bundle or a dock<br>
>> icon. OSX sees that an existing Firefox is running and just sends it a<br>
>> message, a new Firefox instance doesn't even start. I've made no changes<br>
>> here.<br>
>><br>
>> Windows is the slightly more complex case. When run Firefox attempts to<br>
>> find an already running Firefox. If one exists it passes its command line<br>
>> off to it and quits. The -no-remote command line argument is a way to<br>
>> bypass this behaviour, running with it will stop the new Firefox from<br>
>> attempting to find an existing instance or becoming and instance that can<br>
>> be found by other instances. Basically there can only be one Firefox open<br>
>> that can be found by future invocations. The -new-instance command line<br>
>> argument is parsed on Windows ... and then ignored.<br>
>><br>
>> Finally there is Linux. The more exciting case. Unless -no-remote or<br>
>> -new-instance are passed on startup linux will search for an existing<br>
>> version of Firefox based on a few criteria .. which varies a little<br>
>> depending on whether we're using dbus remoting or X remoting. We use X<br>
>> remoting if we are using X11 windows, and dbus if not (and dbus is<br>
>> supported). In both cases on startup Firefox attempts to find an existing<br>
>> instance of Firefox with the same remoting name (or you can provide a<br>
>> different remoting name with -a on the command line). dev-edition has one<br>
>> remoting name, all other versions of firefox have a different one. If there<br>
>> is more than one .. which one wins seems undefined. You can additionally<br>
>> pass "-P <profile name>" in which case Firefox will only select an existing<br>
>> instance running the named profile. On X remoting there are a few extras.<br>
>> Passing "-a any" on the command line will find any running Firefox<br>
>> regardless of remoting name. Passing "-u <username>" will consider<br>
>> Firefoxen run by the given user (otherwise it only looks at those run by<br>
>> the current user). -no-remote means FIrefox doesn't register itself to be<br>
>> found by future instances. -no-remote or -new-instance means we don't look<br>
>> for existing instances on startup.<br>
>><br>
>> So that's all rather complicated. To make matters more fun the linux and<br>
>> windows implementations are handled by totally separate code running at<br>
>> different times during startup. The two key problems here were that windows<br>
>> completely didn't support more than one instance running, unless all but<br>
>> one were -no-remote, and linux was horribly complex and again unless you<br>
>> ran with command line arguments didn't support more than one Firefox at a<br>
>> time. We wanted something that allowed running Firefox release and Firefox<br>
>> beta and Firefox nightly with no special arguments at the same time.<br>
>><br>
>> So I have done three things. Removed support for some of the things Linux<br>
>> supported. Made the code a lot more shared between windows and linux so<br>
>> things happen at the same time regardless of platform and both platform<br>
>> have what should be identical behaviours. Changed the order of when some<br>
>> things happen.<br>
>><br>
>> What did I remove? Support for remoting to a different remoting name and a<br>
>> different user. Both seem unlikely to be useful for normal use cases, the<br>
>> latter frankly feels like a security risk.<br>
>><br>
>> *How does it all work now?*<br>
>><br>
>> OSX hasn't changed, maybe we'll want to do some changes here, but for now<br>
>> it already allows running different versions of Firefox so long as they are<br>
>> using different profiles, which is the default. So for the rest of this<br>
>> assume I'm talking about Linux (dbus or x11) and Windows. They all should<br>
>> behave the same.<br>
>><br>
>> The new remoting does everything based on profile. When starting Firefox<br>
>> we do normal profile selection, which includes considering any -P and<br>
>> --profile command line arguments. Once we've selected a profile we attempt<br>
>> to find an existing Firefox instance using that profile. If one is found we<br>
>> send it our command line arguments and quit. If not continue start up.<br>
>> Since different installs of Firefox use different profiles by default this<br>
>> generally means that running Beta would pass off to an existing Beta. Same<br>
>> for other installs. It also means if you do "firefox -P foo -url<br>
>> <a href="http://www.google.com" rel="noreferrer" target="_blank">www.google.com</a>" we'll open that url in profile Foo, either by using an<br>
>> existing Firefox using profile Foo or by starting with profile Foo.<br>
>><br>
>> -no-remote and -new-instance still exist. Right now they do the same<br>
>> thing, they make Firefox not look for existing instances and not listen for<br>
>> remoting from future instances. They are pretty pointless now though, the<br>
>> only case where they would have an effect is when a second instance is<br>
>> trying to use a profile that is already used by an existing instance ... at<br>
>> which point we'll show the profile locked dialog on startup and refuse to<br>
>> startup anyway.<br>
>><br>
>> The most visible side-effect that folks have started seeing from this<br>
>> change is caused by waiting for profile selection to occur before<br>
>> attempting to remote. If Firefox is configured to always show the profile<br>
>> manager on startup then attempts to open links from outside apps will cause<br>
>> the profile manager to show, because that is what selects the profile.<br>
>> Selecting the profile of an already running Firefox from the UI will then<br>
>> remote to that Firefox (barring a bug that should be fixed in the next<br>
>> nightly), but this is a change in behaviour and honestly not one I'd<br>
>> spotted before landing. In some ways the new behaviour kinda makes sense<br>
>> (if there wasn't already a Firefox running you'd get the profile UI<br>
>> previously too) but I can see how it is confusing too so it might be worth<br>
>> considering changing something here, we'd just have to figure out what<br>
>> profile we should use in this case.<br>
>><br>
>> The other thing that might be confusing is that the version or install of<br>
>> Firefox you try to launch doesn't affect which version or install of<br>
>> Firefox you might end up remoting to. This has always been the case on<br>
>> Windows and normally the case on Linux, unless you pass an extra command<br>
>> line argument though so I'm not too concerned here.<br>
>><br>
>> Hopefully this all makes sense. I'd like to hear if folks think that this<br>
>> is the wrong way to support this and if you spot any issues with it that I<br>
>> haven't.<br>
>><br>
</blockquote></div>