Re: Incoming Change: try pushes from before Feb 4 will not start a decision task
@tomprince reminds me that it's important to note these changes were uplifted to the release branches, so pushing release branches to try should continue to work without any issue. Dustin On Mon, Mar 11, 2019 at 6:33 PM Dustin Mitchell wrote: > I am in the process of landing > https://bugzilla.mozilla.org/show_bug.cgi?id=1526979 > which changes the way we trigger decision tasks to make them more > predictable and debuggable. > > In the process, I landed the necessary in-tree support in > https://phabricator.services.mozilla.com/D18288 > https://phabricator.services.mozilla.com/D18269 > which hit mozilla-central on Feb 4. > > I will be changing the configuration for try to use the "new way" this > Thursday. Once that is done, try pushes which do not include the in-tree > support (that is, which are based on a push more than a month old) will > result in a failed decision task. The fix is to include the above two > changes in your try push. > > I hope this does not cause too much inconvenience! If there's some reason > this change should not take place, please let me know. > > Dustin > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Incoming Change: try pushes from before Feb 4 will not start a decision task
I am in the process of landing https://bugzilla.mozilla.org/show_bug.cgi?id=1526979 which changes the way we trigger decision tasks to make them more predictable and debuggable. In the process, I landed the necessary in-tree support in https://phabricator.services.mozilla.com/D18288 https://phabricator.services.mozilla.com/D18269 which hit mozilla-central on Feb 4. I will be changing the configuration for try to use the "new way" this Thursday. Once that is done, try pushes which do not include the in-tree support (that is, which are based on a push more than a month old) will result in a failed decision task. The fix is to include the above two changes in your try push. I hope this does not cause too much inconvenience! If there's some reason this change should not take place, please let me know. Dustin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Running different instances of Firefox side-by-side
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 wrote: > > > On Mon, Mar 11, 2019 at 11:35 AM Dave Townsend > 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 " 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 " 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
Re: Running different instances of Firefox side-by-side
On Mon, Mar 11, 2019 at 11:35 AM Dave Townsend 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 " 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 " 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
Running different instances of Firefox side-by-side
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 " 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 " 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
[desktop] Bugs logged by Desktop Release QA in the last 7 days
Hello, Here's the list of new issues found and filed by the Desktop Release QA team in the last 7 days. Additional details on the team's priorities last week, as well as the plans for the current week are available at: https://tinyurl.com/y49pb29l. Bugs logged by Desktop Release QA in the last 7 days: Firefox: Preferences NEW - https://bugzil.la/1532625 - Font preferences are confusing because overall font pref is governed by default of serif/sans-serif, and changes don't take effect in the prefs Firefox: Preferences NEW - https://bugzil.la/1532633 - Unable to edit keyword after switching between “Search” and “General” options Firefox: Enterprise Policies ASSIGNED - https://bugzil.la/1532674 - The Disable Addon policy causes an infinite load in the about:addons page Firefox: Preferences RESOLVED FIXED - https://bugzil.la/1532685 - The about:preferences help button opens support page twice (opens two tabs/windows instead of one) Firefox: Preferences RESOLVED FIXED - https://bugzil.la/1532688 - [MacOS] The minimum font size button is truncated Firefox: Preferences ASSIGNED - https://bugzil.la/1532701 - The "Always check if Firefox is your default browser" checkbox status can be changed even though it is locked Firefox: Preferences NEW - https://bugzil.la/1532931 - Searching “True” or “False” in about:preferences returns the same (bogus-looking) results Firefox: Preferences NEW - https://bugzil.la/1532948 - Cookies,data and cache disk size value from about:preferences#privacy is not updating accordingly after closing FF Firefox: Preferences NEW - https://bugzil.la/1533294 - Searching strings from Permissions in about:preferences and selecting Privacy and Security ads another “Permissions” string Firefox: Preferences NEW - https://bugzil.la/1533329 - The "Remove Selected" button is grayed out after multiple websites are selected Firefox: Preferences NEW - https://bugzil.la/1533358 - Details button from the Show Update History is barely visible Firefox: Site Identity and Permission Panels NEW - https://bugzil.la/1533362 - The shield isn't displayed when opening link in new tab Firefox: General NEW - https://bugzil.la/1533386 - [Ubuntu] Firefox doesn't remember the location for HTML windows Firefox: Preferences RESOLVED FIXED - https://bugzil.la/1533389 - The applications list in Preferences leaves the top entry (and duplicates it) when filtering/sorting Core: Panning and Zooming NEW - https://bugzil.la/1532294 - Facebook messenger - chat bubble background glitches on scroll Core: Disability Access APIs NEW - https://bugzil.la/1532603 - Crash in [@ markNodeAsNonreusableIfInAncestor] Core: Disability Access APIs RESOLED WORKSFORME - https://bugzil.la/1532610 - Crash in [@ CxxThrowException] while NVDA is enabled Core: WebRTC: Audio/Video NEW - https://bugzil.la/1533347 - [Ubuntu] Tab crash when performing calls between Ubuntu and OS X on ciscospark.com Core: WebRTC: Audio/Video NEW - https://bugzil.la/1533364 - Facebook call ends when switching to the webcam microphone Core: Disability Access APIs NEW - https://bugzil.la/1533728 - NVDA reads url's instead of show names on Netflix DevTools: Inspector NEW - https://bugzil.la/1533353 - Grid lines overlap css elements when using the browser zoom. This is available as a Bugzilla bug list as well: https://tinyurl.com/y2tshnvf Regards, Mihai Boldan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
