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
