Since there were no further concerns voiced to the final proposal I've gone ahead and landed the change in https://bugzilla.mozilla.org/show_bug.cgi?id=1653384. To be respected you must now set the MOZ_FORCE_DISABLE_E10S environment variable to the full application version. `mach run --disable-e10s` has been updated to do this automatically.
On Wed, Jun 17, 2020 at 1:45 PM Gijs Kruitbosch <[email protected]> wrote: > Having read all the responses here, I guess an adjusted proposal would > be to switch to requiring the variable to be set to the build's version. > Does that seem like it'd address your concerns? > > There were two other points raised that I wanted to briefly respond to: > > > What does this proposal mean for ./mach run --disable-e10s ? > > In the adjusted proposal, this would set the right env var, as it does > today, so there should be no difference. > > > * particularly on Windows where even basic `printf` and `dump` from the > child process don't show up in the console. > > As I have suggested to you elsewhere, I think this is a serious problem > that inhibits adoption of Windows as a development platform for Firefox, > and we should address this orthogonal to whatever we do with e10s. > Inasmuch as this isn't already covered in > https://bugzilla.mozilla.org/show_bug.cgi?id=1257155, please file bugs. > > Note that you do not actually need to disable e10s, running with the > `-attach-console` commandline switch (which you need anyway, also if you > disable e10s) and the `MOZ_DISABLE_CONTENT_SANDBOX=1` env var are > sufficient to get dump logging from the content process in my testing. > > > Longer-term, it would be useful to think about how else we could cater > to your debugging needs, without completely disabling e10s - whether > that's something like the layout debugger (which was switched to using > e10s a while back) to reduce the noise of the rest of Firefox, or a way > to directly inspect the a11y API output of the content process, or > whatever it is - it is not ultimately feasible to keep "supporting" > several modes of operation forever. > > ~ Gijs > > > On 10/06/2020 19:58, David Major 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 <[email protected]> > 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 < > [email protected] > >>> > >> 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 > >>> [email protected] > >>> https://mail.mozilla.org/listinfo/firefox-dev > >>> > >> _______________________________________________ > >> dev-platform mailing list > >> [email protected] > >> https://lists.mozilla.org/listinfo/dev-platform > >> > > _______________________________________________ > dev-platform mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
