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 <gijskruitbo...@gmail.com>
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 <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

Reply via email to