Yes sorry, corrected that. On Thu, Mar 14, 2019 at 6:19 AM Marco Castelluccio < mcastelluc...@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 <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
