For the win32k experiment, we need to use an enrollment pref.

Normandy flip preferences on the default branch during startup - they are not persisted flips in durable storage. This flipping happens after the time of content process startup. So even if Normandy flipped win32k lockdown on, the next time we started Firefox, we still wouldn't see the pref on during our first content process startup. In theory we could ask Normandy to flip the preference on the user branch (so we see it when we start our first content process after restart) but this would overwrite user setting and we don't want to do that.

One noteworthy thing is that presently we store the result of the the pref check in a static variable, so it is unchanged for the lifetime of browser operation. I don't thik we need to change this.

The enrollment pref:

Fission uses two enrollment prefs: fission.experiment.enrollmentStatus and fission.experiment.startupEnrollmentStatus - these are documented in nsAppRunner.cpp. Basically, because of the Normandy-setting-prefs-in-the-default-branch behavior, when an experiment enables Fission here's what happens.

1. During browser execution, Normandy sets fission.experiment.enrollmentStatus in the default branch.
2. When the above pref is changed, an observer changes fission.experiment.startupEnrollmentStatus in the user branch.
3. On next browser startup, fission.experiment.startupEnrollmentStatus is checked (at the bottom of a priority list) to determine if Fission should be enabled.

We're going to do basically the same thing. The code should work whether win32k lockdown is enabled or disabled by default.

To determine if win32k lockdown should be enabled, we're going to look at the following values, in order:

• Safe Mode - in Safe Mode, we should not enable win32k lockdown
• Env Var - if MOZ_ENABLE_WIN32K is set, we should not enable win32k lockdown
• Existing checks for things like WebGL Remoting being disabled
• If security.sandbox.content.win32k-disable has been set by the user to a non-default value, we obey it.
• If security.sandbox.content.win32k-experiment.startupEnrollmentStatus is true, we enable win32k lockdown

We're going to create the following prefs:

security.sandbox.content.win32k-experiment.enrollmentStatus - Set by Normandy in the default branch.

security.sandbox.content.win32k-experiment.startupEnrollmentStatus - Set during runtime by copying the value from above into the user branch.

These prefs can have the values, copied from fission:

• Unenrolled
• Control - win32k Lockdown is disabled because the user is enrolled in the experiment in the control group
• Treatment - win32k Lockdown is enabled because the user is enrolled in the experiment in the treatment group
• DisqualifiedFromTreatmentRequirements - The user was enrolled in the treatment group, but got disqualified because they didn't meet the requirements (e.g. WebGL Remoting)
• DisqualifiedFromTreatmentUserChange - The user was enrolled in the treatment group, but they either changed the win32k pref manually, ran in safe mode, or set the env var.

We're going to expand ContentWin32kLockdownState to have the following values:

• LockdownEnabled = 1 - after this work, this value will no longer appear in Telemetry.
• MissingWebRender = 2
• OperatingSystemNotSupported = 3
• PrefNotSet = 4 - after this work, this value will no longer appear in Telemetry.
• MissingRemoteWebGL = 5
• DisabledByEnvVar = 6 - MOZ_ENABLE_WIN32K is set
• DisabledBySafeMode = 7
• DisabledByE10S = 8 - E10S is disabled for whatever reason
• DisabledByUserPref = 9 - The user manually set security.sandbox.content.win32k-disable to false
• EnabledByUserPref = 10 - The user manually set security.sandbox.content.win32k-disable to true
• DisabledByControlGroup = 11 - The user is in the Control Group, so it is disabled
• EnabledByTreatmentGroup = 12 - The user is in the Treatment Group, so it is enabled
• DisabledByDefault = 13 - The default value of the pref is false
• EnabledByDefault = 14 - The default value of the pref is true

The precedence order for these values will be:

• DisabledBySafeMode
• DisabledByEnvVar
• DisabledByE10S
• OperatingSystemNotSupported
• MissingWebRender
• MissingRemoteWebGL
• DisabledByUserPref or EnabledByUserPref
• DisabledByControlGroup or EnabledByTreatmentGroup
• DisabledByDefault or EnabledByDefault

There's a bunch of supporting tiny functions and infrastructure in nsAppRunner.cpp that I expect will need to be duplicated for win32k.

Another note, as I work on the code:

Fission has a fission.autostart.session that is set in the parent and locked. Its value doesn't change for the session and requires a restart to be changed. It needs this because the pref is read in the content process. We don't need this, because our pref is only read in the parent process, so the existing practice of using a static variable is sufficient for us.

Depends on D136801

Depends on D136802

First round of testing seems good; I need to look at the marionette test that Fission has and see if I can do something like that.

I generated the tests using a script, which I'm checking in
so it's not lost.

Depends on D137325

Differential Revsion: https://phabricator.services.mozilla.com/D137324

Depends on D136802

https://hg.mozilla.org/mozilla-central/rev/4274a4938be8
https://hg.mozilla.org/mozilla-central/rev/c203cc41f8aa
https://hg.mozilla.org/mozilla-central/rev/5b874e2aae36
https://hg.mozilla.org/mozilla-central/rev/fdc6d4dad4db
https://hg.mozilla.org/mozilla-central/rev/c3c7fd4ae589