On 26/04/2019 18:05, Joel Maher wrote:
This was announced last night:
https://groups.google.com/forum/#!topic/mozilla.dev.platform/k-irJtmCcqg

This seems to suggest we shouldn't make fennec-related changes until the 71 cycle and that we're not 100% certain that we won't ship it past esr68.

On 25/04/2019 21:57, Bobby Holley wrote:
> As long as we're certain that we won't ship Fennec past ESR68, 1proc will
> cease to be a user-accessible configuration once Nightly moves to 69 in 2.5
> weeks.
>
> Once that happens, I propose the following steps, in order:
> (1) Remove support for the e10s pref, per Gijs' suggestion above.
> (2) Define and launch a small "1proc-smoketest" job, based on
> mochitest-plain, with a handful of tests across various components to
> verify that things mostly work.
> (3) Turn off the existing 1proc jobs.
>
> Does this seem like a reasonable path forward?

So I'm not sure how this jives with the Fennec plans as per the above.

Even if it's fine to make such changes against a reduced-test-coverage fennec on 69, I'd like to push and ask if we can reasonably switch the enabling/disabling of e10s to an env var (and force e10s off via a build flag for fennec) on the 68 cycle still? (We'd keep `--disable-e10s` working on mach for developer use as it does today.)

I think from a security perspective we should avoid continuing to ship something ("even" on esr) where users can either still (relatively) easily manually disable e10s or get grandfathered into having it disabled on desktop. We renamed some stuff to "allow viruses to take over your computer" in the past - I think in 2019, turning off e10s and/or sandboxing on desktop is similarly problematic.

Gijs
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to