Re: Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward
> On 25 Apr 2019, at 8:49 am, Bobby Holley wrote. >> > > I think the tradeoff boils down to (a) how many developers are using > non-e10s debugging, with what frequency, versus (b) how much ongoing > maintenance work is required across various components to keep non-e10s > working. We all have intuition about these things, but I doubt we have hard > data. > > I'm open to the argument that my proposal is too aggressive. We could > certainly try the muddle approach for a while and see how it goes, and how > often 1proc breaks in practice. I don't think we can justify continuing to > run the full suite of 1proc tests as tier-1, but we could potentially run a > few smoketests, which might keep the builds usable enough for debugging. > > If anyone is chomping at the bit to remove 1proc support from their module, > please speak up. I am one of those developers that find non-e10s essential to debug core features. Debugging in e10s adds a big overhead in the effort required to determine on the why something isn't working as it should. When debugging HW specialised features (for media those are running in the GPU process), in e10s you always hit timeouts that cause a cascade of failures elsewhere. Of course we can do without, but at the expense of time and convenience. Before non-e10s support is removed, I'd love to see better development/debugging tools, particularly on Windows added to help our workflow. I knew this day would come, tbh I'm surprise non-e10s has lived for so long. However, I don't believe my workflow is unique to whomever is working on gecko. Jean-Yves ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward
On Wed, Apr 24, 2019 at 4:30 PM Mike Hommey wrote: > On Wed, Apr 24, 2019 at 03:49:47PM -0700, Bobby Holley wrote: > > On Wed, Apr 24, 2019 at 2:21 PM David Major wrote: > > > > > On Wed, Apr 24, 2019 at 1:39 PM Bobby Holley > > > wrote: > > > > > > > > Thanks Mike! > > > > > > > > So Fennec is the last remaining non-e10s configuration we ship to > users. > > > > Given that Fennec test coverage is somewhat incomplete, we probably > want > > > to > > > > keep running desktop 1proc tests until Fennec EOL. We don't strictly > need > > > > the browser-chrome tests, but we should probably avoid intentionally > > > > breaking non-e10s browser-chrome as long as engineers may still need > to > > > > debug non-e10s test failures. > > > > > > > > After Fennec EOL, we basically have two options: a clean break where > we > > > rip > > > > out non-e10s support entirely, or a more muddled approach where we > > > > halfheartedly keep it working as a handy engineering hack as long as > is > > > > practical. I think we should do the former. > > > > > > > > I don't want to downplay the handiness - being able to test and > debug the > > > > browser in a single process can eliminate complexity and > non-determinism, > > > > and save a lot of time. But at some point there's going to be a > piece of > > > > core functionality that's too much work to keep supporting under > > > non-e10s - > > > > and agonizing over that threshold on an ongoing basis is not a good > use > > > of > > > > anyone's time. > > > > > > Why not have the conversation when such a piece of core functionality > > > arises? It's a much more convincing argument when you can say > > > "non-e10s needs to go away in order to support X". > > > > > > > I'm concerned about the impact of a gradual degradation of the e10s > > experience and an ambiguous bar as to exactly how much work developers > are > > expected to do to support it. It's effectively going to be a Tier-3 > > platform with no owner. > > > > > > > > > > In the meantime, single process debugging is a tremendous saver of > > > time and hassle, and we'd need a great reason to disable it. I'm not > > > convinced that one currently exists. > > > > > > > I think the tradeoff boils down to (a) how many developers are using > > non-e10s debugging, with what frequency, versus (b) how much ongoing > > maintenance work is required across various components to keep non-e10s > > working. We all have intuition about these things, but I doubt we have > hard > > data. > > > > I'm open to the argument that my proposal is too aggressive. We could > > certainly try the muddle approach for a while and see how it goes, and > how > > often 1proc breaks in practice. I don't think we can justify continuing > to > > run the full suite of 1proc tests as tier-1, but we could potentially > run a > > few smoketests, which might keep the builds usable enough for debugging. > > > > If anyone is chomping at the bit to remove 1proc support from their > module, > > please speak up. > > I'm not versed on the details of non-e10s, but is it so different from > e10s that it could easily break? Probably not "so different" in relative terms, since we try to abstract over the distinction wherever possible. But browsers are big and abstractions are rarely perfect, so there's a long tail of special-cases that do different things depending on the process model. If we're not testing it, it will eventually break. > Or are we more concerned, long term, > that non-e10s would block us from making some architectural changes to > e10s? > If a big architectural change gets blocked (which will probably happen eventually), that will simplify the discussion. So I think the question here is how much fiddling we should do to keep it working in the interim. > Relatedly, do we have a history of having broken non-e10s with e10s > changes? > I doubt there's a comprehensive list, but bug 1530977 is the example that recently came across my desk. That bug is specific to hardware acceleration on Windows, which is why it wasn't caught by the linux 1proc tests. Once we those off, the regression surface will widen from platform-specific code to all of Gecko. I suspect that will result in an increased rate in regressions, but it's hard to guess exactly how much. > > Mike > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward
On Wed, Apr 24, 2019 at 03:49:47PM -0700, Bobby Holley wrote: > On Wed, Apr 24, 2019 at 2:21 PM David Major wrote: > > > On Wed, Apr 24, 2019 at 1:39 PM Bobby Holley > > wrote: > > > > > > Thanks Mike! > > > > > > So Fennec is the last remaining non-e10s configuration we ship to users. > > > Given that Fennec test coverage is somewhat incomplete, we probably want > > to > > > keep running desktop 1proc tests until Fennec EOL. We don't strictly need > > > the browser-chrome tests, but we should probably avoid intentionally > > > breaking non-e10s browser-chrome as long as engineers may still need to > > > debug non-e10s test failures. > > > > > > After Fennec EOL, we basically have two options: a clean break where we > > rip > > > out non-e10s support entirely, or a more muddled approach where we > > > halfheartedly keep it working as a handy engineering hack as long as is > > > practical. I think we should do the former. > > > > > > I don't want to downplay the handiness - being able to test and debug the > > > browser in a single process can eliminate complexity and non-determinism, > > > and save a lot of time. But at some point there's going to be a piece of > > > core functionality that's too much work to keep supporting under > > non-e10s - > > > and agonizing over that threshold on an ongoing basis is not a good use > > of > > > anyone's time. > > > > Why not have the conversation when such a piece of core functionality > > arises? It's a much more convincing argument when you can say > > "non-e10s needs to go away in order to support X". > > > > I'm concerned about the impact of a gradual degradation of the e10s > experience and an ambiguous bar as to exactly how much work developers are > expected to do to support it. It's effectively going to be a Tier-3 > platform with no owner. > > > > > > In the meantime, single process debugging is a tremendous saver of > > time and hassle, and we'd need a great reason to disable it. I'm not > > convinced that one currently exists. > > > > I think the tradeoff boils down to (a) how many developers are using > non-e10s debugging, with what frequency, versus (b) how much ongoing > maintenance work is required across various components to keep non-e10s > working. We all have intuition about these things, but I doubt we have hard > data. > > I'm open to the argument that my proposal is too aggressive. We could > certainly try the muddle approach for a while and see how it goes, and how > often 1proc breaks in practice. I don't think we can justify continuing to > run the full suite of 1proc tests as tier-1, but we could potentially run a > few smoketests, which might keep the builds usable enough for debugging. > > If anyone is chomping at the bit to remove 1proc support from their module, > please speak up. I'm not versed on the details of non-e10s, but is it so different from e10s that it could easily break? Or are we more concerned, long term, that non-e10s would block us from making some architectural changes to e10s? Relatedly, do we have a history of having broken non-e10s with e10s changes? Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward
On Wed, Apr 24, 2019 at 2:21 PM David Major wrote: > On Wed, Apr 24, 2019 at 1:39 PM Bobby Holley > wrote: > > > > Thanks Mike! > > > > So Fennec is the last remaining non-e10s configuration we ship to users. > > Given that Fennec test coverage is somewhat incomplete, we probably want > to > > keep running desktop 1proc tests until Fennec EOL. We don't strictly need > > the browser-chrome tests, but we should probably avoid intentionally > > breaking non-e10s browser-chrome as long as engineers may still need to > > debug non-e10s test failures. > > > > After Fennec EOL, we basically have two options: a clean break where we > rip > > out non-e10s support entirely, or a more muddled approach where we > > halfheartedly keep it working as a handy engineering hack as long as is > > practical. I think we should do the former. > > > > I don't want to downplay the handiness - being able to test and debug the > > browser in a single process can eliminate complexity and non-determinism, > > and save a lot of time. But at some point there's going to be a piece of > > core functionality that's too much work to keep supporting under > non-e10s - > > and agonizing over that threshold on an ongoing basis is not a good use > of > > anyone's time. > > Why not have the conversation when such a piece of core functionality > arises? It's a much more convincing argument when you can say > "non-e10s needs to go away in order to support X". > I'm concerned about the impact of a gradual degradation of the e10s experience and an ambiguous bar as to exactly how much work developers are expected to do to support it. It's effectively going to be a Tier-3 platform with no owner. > > In the meantime, single process debugging is a tremendous saver of > time and hassle, and we'd need a great reason to disable it. I'm not > convinced that one currently exists. > I think the tradeoff boils down to (a) how many developers are using non-e10s debugging, with what frequency, versus (b) how much ongoing maintenance work is required across various components to keep non-e10s working. We all have intuition about these things, but I doubt we have hard data. I'm open to the argument that my proposal is too aggressive. We could certainly try the muddle approach for a while and see how it goes, and how often 1proc breaks in practice. I don't think we can justify continuing to run the full suite of 1proc tests as tier-1, but we could potentially run a few smoketests, which might keep the builds usable enough for debugging. If anyone is chomping at the bit to remove 1proc support from their module, please speak up. > > Other opinions? > > > > On Tue, Apr 23, 2019 at 1:30 PM Mike Conley wrote: > > > > > Hey folks, > > > > > > For Desktop, I don't believe there are any normal conditions under > which > > > our users will have e10s disabled. [1] is where the decision gets > made, and > > > it looks like these days, the only thing that will disable e10s is if > the > > > user sets `browser.tabs.remote.autostart` to false themselves, or if a > > > MOZ_FORCE_DISABLE_E10S environment variable is set. I don't think > either of > > > those are ever set by Mozilla these days. > > > > > > There was a case a few months back where e10s was disabled for users > with > > > certain screen readers back for Firefox 60. Since that time, those > screen > > > readers have updated to become more stable with e10s enabled. > > > Unfortunately, I don't have a reference to the bug(s) where that > occurred, > > > but I spoke to yzen in #accessibility, and Firefox 60 ESR is the last > > > supported version where this e10s-disabling occurs on Desktop. > > > > > > So, to sum, I'm reasonably confident that, outside of Firefox 60 ESR, > > > e10s-disabled is not a mode that we ship to any of our users. We can > > > trigger it by pref flips or environment variables, but that's it. > > > > > > Mobile is another story - according to the fine folks in #mobile, > Fennec > > > still runs Gecko in non-e10s mode. > > > > > > To circle back to Gijs's questions: > > > > > > 1. do we still consider running desktop Firefox with e10s disabled a > > >> supported configuration? > > >> > > > > > > Outside of Firefox 60 ESR, no, I don't believe so. > > > > > > 2. Will we need to turn it off on esr68 in the same circumstances where > > >> that happens on esr60? > > >> > > > > > > According to yzen from the Accessibility team, no, we won't. > > > > > > 3. If the answer to either of the previous 2 questions is 'yes', do we > > >> think it's acceptable not to run desktop tests on the configuration? > > >> > > > > > > Answers are no. > > > > > > 4. If the answer to both (1) and (2) is 'no', can we remove support for > > >> the pref and running desktop Firefox without e10s ? Some of the > > >> codepaths are not unified and so there is effectively dead code that > > >> we're lugging around for what would be no reason. (Note: a significant > > >> proportion isn't dead because even in e10s, we
Re: Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward
On Wed, Apr 24, 2019 at 1:39 PM Bobby Holley wrote: > > Thanks Mike! > > So Fennec is the last remaining non-e10s configuration we ship to users. > Given that Fennec test coverage is somewhat incomplete, we probably want to > keep running desktop 1proc tests until Fennec EOL. We don't strictly need > the browser-chrome tests, but we should probably avoid intentionally > breaking non-e10s browser-chrome as long as engineers may still need to > debug non-e10s test failures. > > After Fennec EOL, we basically have two options: a clean break where we rip > out non-e10s support entirely, or a more muddled approach where we > halfheartedly keep it working as a handy engineering hack as long as is > practical. I think we should do the former. > > I don't want to downplay the handiness - being able to test and debug the > browser in a single process can eliminate complexity and non-determinism, > and save a lot of time. But at some point there's going to be a piece of > core functionality that's too much work to keep supporting under non-e10s - > and agonizing over that threshold on an ongoing basis is not a good use of > anyone's time. Why not have the conversation when such a piece of core functionality arises? It's a much more convincing argument when you can say "non-e10s needs to go away in order to support X". In the meantime, single process debugging is a tremendous saver of time and hassle, and we'd need a great reason to disable it. I'm not convinced that one currently exists. > Other opinions? > > On Tue, Apr 23, 2019 at 1:30 PM Mike Conley wrote: > > > Hey folks, > > > > For Desktop, I don't believe there are any normal conditions under which > > our users will have e10s disabled. [1] is where the decision gets made, and > > it looks like these days, the only thing that will disable e10s is if the > > user sets `browser.tabs.remote.autostart` to false themselves, or if a > > MOZ_FORCE_DISABLE_E10S environment variable is set. I don't think either of > > those are ever set by Mozilla these days. > > > > There was a case a few months back where e10s was disabled for users with > > certain screen readers back for Firefox 60. Since that time, those screen > > readers have updated to become more stable with e10s enabled. > > Unfortunately, I don't have a reference to the bug(s) where that occurred, > > but I spoke to yzen in #accessibility, and Firefox 60 ESR is the last > > supported version where this e10s-disabling occurs on Desktop. > > > > So, to sum, I'm reasonably confident that, outside of Firefox 60 ESR, > > e10s-disabled is not a mode that we ship to any of our users. We can > > trigger it by pref flips or environment variables, but that's it. > > > > Mobile is another story - according to the fine folks in #mobile, Fennec > > still runs Gecko in non-e10s mode. > > > > To circle back to Gijs's questions: > > > > 1. do we still consider running desktop Firefox with e10s disabled a > >> supported configuration? > >> > > > > Outside of Firefox 60 ESR, no, I don't believe so. > > > > 2. Will we need to turn it off on esr68 in the same circumstances where > >> that happens on esr60? > >> > > > > According to yzen from the Accessibility team, no, we won't. > > > > 3. If the answer to either of the previous 2 questions is 'yes', do we > >> think it's acceptable not to run desktop tests on the configuration? > >> > > > > Answers are no. > > > > 4. If the answer to both (1) and (2) is 'no', can we remove support for > >> the pref and running desktop Firefox without e10s ? Some of the > >> codepaths are not unified and so there is effectively dead code that > >> we're lugging around for what would be no reason. (Note: a significant > >> proportion isn't dead because even in e10s, we load some > >> browser-provided content in parent process, ie a tab's browser is not > >> always remote/non-same-process -- but even so, there's a bunch of stuff > >> that keys off gMultiProcessBrowser that could be removed.) > >> > > > > Yes, I believe that stuff is probably safe to remove at this point, as > > long those changes don't assume e10s support on Fennec. > > > > -Mike > > > > [1]: > > https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/toolkit/xre/nsAppRunner.cpp#4964-5002 > > > > On Tue, 23 Apr 2019 at 13:35, Dave Townsend wrote: > > > >> Is there still a configuration (ignoring hidden prefs) that can cause a > >> user to end up using non-e10s? If so we should turn these tests back on. > >> > >> On Tue, Apr 23, 2019 at 8:25 AM Joel Maher wrote: > >> > >> > Here is where we initially turned on non-e10s tests for win7: > >> > https://bugzilla.mozilla.org/show_bug.cgi?id=1391371 > >> > > >> > and then moved to linux32: > >> > https://bugzilla.mozilla.org/show_bug.cgi?id=1433276 > >> > > >> > Currently mochitest-chrome and mochitest-a11y run as 1proc in-tree- > >> these > >> > run this way as they do not work with e10s=true. I suspect the > >> > mochitest-chrome is by design and
Re: Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward
Thanks Mike! So Fennec is the last remaining non-e10s configuration we ship to users. Given that Fennec test coverage is somewhat incomplete, we probably want to keep running desktop 1proc tests until Fennec EOL. We don't strictly need the browser-chrome tests, but we should probably avoid intentionally breaking non-e10s browser-chrome as long as engineers may still need to debug non-e10s test failures. After Fennec EOL, we basically have two options: a clean break where we rip out non-e10s support entirely, or a more muddled approach where we halfheartedly keep it working as a handy engineering hack as long as is practical. I think we should do the former. I don't want to downplay the handiness - being able to test and debug the browser in a single process can eliminate complexity and non-determinism, and save a lot of time. But at some point there's going to be a piece of core functionality that's too much work to keep supporting under non-e10s - and agonizing over that threshold on an ongoing basis is not a good use of anyone's time. Other opinions? On Tue, Apr 23, 2019 at 1:30 PM Mike Conley wrote: > Hey folks, > > For Desktop, I don't believe there are any normal conditions under which > our users will have e10s disabled. [1] is where the decision gets made, and > it looks like these days, the only thing that will disable e10s is if the > user sets `browser.tabs.remote.autostart` to false themselves, or if a > MOZ_FORCE_DISABLE_E10S environment variable is set. I don't think either of > those are ever set by Mozilla these days. > > There was a case a few months back where e10s was disabled for users with > certain screen readers back for Firefox 60. Since that time, those screen > readers have updated to become more stable with e10s enabled. > Unfortunately, I don't have a reference to the bug(s) where that occurred, > but I spoke to yzen in #accessibility, and Firefox 60 ESR is the last > supported version where this e10s-disabling occurs on Desktop. > > So, to sum, I'm reasonably confident that, outside of Firefox 60 ESR, > e10s-disabled is not a mode that we ship to any of our users. We can > trigger it by pref flips or environment variables, but that's it. > > Mobile is another story - according to the fine folks in #mobile, Fennec > still runs Gecko in non-e10s mode. > > To circle back to Gijs's questions: > > 1. do we still consider running desktop Firefox with e10s disabled a >> supported configuration? >> > > Outside of Firefox 60 ESR, no, I don't believe so. > > 2. Will we need to turn it off on esr68 in the same circumstances where >> that happens on esr60? >> > > According to yzen from the Accessibility team, no, we won't. > > 3. If the answer to either of the previous 2 questions is 'yes', do we >> think it's acceptable not to run desktop tests on the configuration? >> > > Answers are no. > > 4. If the answer to both (1) and (2) is 'no', can we remove support for >> the pref and running desktop Firefox without e10s ? Some of the >> codepaths are not unified and so there is effectively dead code that >> we're lugging around for what would be no reason. (Note: a significant >> proportion isn't dead because even in e10s, we load some >> browser-provided content in parent process, ie a tab's browser is not >> always remote/non-same-process -- but even so, there's a bunch of stuff >> that keys off gMultiProcessBrowser that could be removed.) >> > > Yes, I believe that stuff is probably safe to remove at this point, as > long those changes don't assume e10s support on Fennec. > > -Mike > > [1]: > https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/toolkit/xre/nsAppRunner.cpp#4964-5002 > > On Tue, 23 Apr 2019 at 13:35, Dave Townsend wrote: > >> Is there still a configuration (ignoring hidden prefs) that can cause a >> user to end up using non-e10s? If so we should turn these tests back on. >> >> On Tue, Apr 23, 2019 at 8:25 AM Joel Maher wrote: >> >> > Here is where we initially turned on non-e10s tests for win7: >> > https://bugzilla.mozilla.org/show_bug.cgi?id=1391371 >> > >> > and then moved to linux32: >> > https://bugzilla.mozilla.org/show_bug.cgi?id=1433276 >> > >> > Currently mochitest-chrome and mochitest-a11y run as 1proc in-tree- >> these >> > run this way as they do not work with e10s=true. I suspect the >> > mochitest-chrome is by design and a11y is a bug. >> > >> > -Joel >> > >> > >> > On Thu, Apr 18, 2019 at 5:47 PM Bobby Holley >> > wrote: >> > >> > > If we're not testing it, we shouldn't be shipping it to users. It >> would >> > be >> > > great if someone familiar with the esr60 situation could confirm that >> we >> > > don't plan to repeat it for esr68. It would also be great if someone >> > could >> > > explain the rationale for running some, but not all of the suites in >> > 1proc >> > > mode. >> > > >> > > Separately, I know some engineers disable e10s locally as a hack to >> > > simplify debugging (e.g [1]). The 1proc
Re: Personally opining that new C++ library facilities should not support non-UTF encodings
I sent this to SG16 (after tweaking it a bit to downplay UTF-16 and UTF-32). On Mon, Apr 22, 2019 at 1:19 PM Henri Sivonen wrote: > > (If you don't care about what I say about character encoding issues in > the context of C++ standardization outside my Mozilla activities, you > can save time by skipping the rest of this email.) > > On my own time outside my Mozilla activities, I was invited to read > and comment on the C++ standardization papers under the purview of the > Unicode Study Group (SG16) of the C++ committee. > > I've drafted a reply in which I opine that _new_ text processing > features (other than character encoding conversion facilities) in the > C++ standard library should only support UTF-8/16/32 and should not > seek to support non-UTF execution encodings and that conversion > facilities should have an API similar encoding_rs's API: > https://hsivonen.fi/p/non-unicode-in-cpp.html > > Based on prior advice from Botond, I'm sending this heads-up here just > in case: If you have a reason why it would be bad from the Mozilla > perspective for me to send the above-linked document to SG16 even with > the personal-capacity disclaimer, please let me know. > > (I expect this to be non-controversial from the Mozilla perspective, > since we already treat the concept of C++ "execution encoding" as a > C++ design bug that we route around.) > > -- > Henri Sivonen > hsivo...@hsivonen.fi > https://hsivonen.fi/ -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
