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