In general, this obviously makes a lot of sense. However, because there is so much extra complication for accessibility when e10s is enabled, I find myself disabling e10s in local opt/debug builds to isolate problems to the core a11y engine (vs the a11y e10s stuff). The ability to do this was instrumental in some of the perf work I've been doing lately. For example, it allowed me to determine that some of the perf problems I had originally attributed to the a11y e10s layer were actually problems in the core a11y engine. I'm sure there's some way I could have achieved that with e10s enabled, but it probably would have taken me weeks longer.
All of that said, I realise this is an obscure case and I don't want to stand in the way of progress; I'm well aware legacy has to die eventually. Nevertheless, I thought I'd at least flag this concern. Btw, the need to isolate the core a11y engine from the a11y e10s stuff is also why some of our a11y tests still run with e10s disabled in automation. Jamie On Thu, Jun 11, 2020 at 4:56 AM David Major <dma...@mozilla.com> wrote: > I agree that it's a bad idea for users to be running permanently with this > setting on their daily driver browsers. > > But the environment variable has been a huge productivity enhancer to > reduce my mental load when setting up an extra-hairy debug session or > taking system traces. > > I wish we could have a way to allow this for one-off cases but not > long-term usage. Unfortunately I can't settle for a proposal like "allow it > only in debug or only in nightlies" because I often need to debug actual > user-facing builds. Is there any way we could build some auto-expiration > into this setting, like maybe you'd have to set the env var equal to the > build ID or today's date? > > > > On Wed, Jun 10, 2020 at 2:44 PM Dave Townsend <dtowns...@mozilla.com> > wrote: > > > Non-e10s is such a different environment that I don't think we have any > > hope of keeping it working without running the full test suite in that > mode > > and I don't think anyone wants to do that. Now that this has started > > breaking I think it is actively harmful to our users for us to allow them > > to disable e10s. > > > > On Wed, Jun 10, 2020 at 11:30 AM Gijs Kruitbosch < > gijskruitbo...@gmail.com > > > > > wrote: > > > > > (Copied to fx-dev; Replies to dev-platform please.) > > > > > > Hello, > > > > > > Just over a year ago, I started a discussion[0] about our support for > > > disabling e10s. The outcome of that was that we removed support for > > > disabling e10s with a pref on Desktop Firefox with version 68, except > > > for use from automation. We kept support for using the environment > > > variable. [1] > > > > > > Last week, we released Firefox 77, which turned out to break all > > > webpages sent using compression (like gzip) if you had disabled e10s > > > using this environment variable. [2] > > > > > > So here we are again. I'd like to propose we also stop honouring the > > > environment variable unless we're running tests in automation. We > > > clearly do not have sufficient test coverage to guarantee basic things > > > like "the browser works", it lacks security sandboxing, and a number of > > > other projects require it (fission, gpu process, socket process, ...), > > > so I think it's time to stop supporting this configuration at all. > > > > > > I hope to make this change for the 79 cycle. I'm open to arguments > > > either way about what to do for 78 esr (assuming the patch for 79 turns > > > out to be simple; the work to remove the pref had a number of annoying > > > corner-cases at the time). > > > > > > Please speak up if you think that this plan needs adjusting. > > > > > > ~ Gijs > > > > > > > > > [0] > > > > > > > > > https://groups.google.com/d/msg/mozilla.dev.platform/cJMzxi7_PmI/Pi1IOg_wCQAJ > > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1548941 > > > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1638652 > > > _______________________________________________ > > > firefox-dev mailing list > > > firefox-...@mozilla.org > > > https://mail.mozilla.org/listinfo/firefox-dev > > > > > _______________________________________________ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
