If out-of-process WebGL and the GPU process are both enabled, several things break:

• The GfxInfo component isn't enabled.
• The screen manager component isn't enabled.
• The GfxInfo component needs to be pre-initialized on the main thread, because initialization is main-thread-only and remote WebGL uses it on the compositor thread
• Nothing launches the glxtest process, so initialization fails.

I have a patch for this, but it probably needs some help; the last two items are wedged into GPUParent::RecvInit (which is where GfxInfo is preloaded on Windows) and I don't know if that's right, especially for glxtest.

I now have two patches for this: one of them is simple, but the GPU process has to re-do the whole thing with forking a process to call glxtest; the other one is more complex and uses GfxInfoBase::SetFeatureStatus to give the GPU process the info that the parent process already computed. Which version should I send for review?

On second thought I think I'm just going to send the fancier patch; it's not that complicated, and it avoids the possibility of a startup performance regression from the second glxtest invocation.

Out-of-process WebGL needs GfxInfo to exist in the composition
process (which is the GPU process if it exists and the parent process
otherwise). This patch enables the Linux version of that component in
the GPU process; the IPC currently used to give content processes copies
of the parent's GPU info is extended to also send it to the GPU process.

Backed out 2 changesets (Bug 1654957) for causing leaks.

Backout link: https://hg.mozilla.org/integration/autoland/rev/2ee7b3950f0f2676eb9e5cfd97660db98e7f7ffc

Push with failures:
https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception&revision=4c06ff10c0756403e4bee97d2ac2fc51f036b9ce&selectedTaskRun=VgVHBIdoQ4OR8RKUENHSEg.0

https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&searchStr=windows%2C10%2Cx64%2Cdebug%2Cweb%2Cplatform%2Ctests%2Ctest-windows10-64%2Fdebug-web-platform-tests-crashtest-e10s%2Cwc&fromchange=00743b9e991503c308135d808afa0c42b77e36ea&tochange=2ee7b3950f0f2676eb9e5cfd97660db98e7f7ffc&selectedTaskRun=XemeN6RUQeOg7PZG3PKRKg.0

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=312013363&repo=autoland&lineNumber=975

At the moment it only affects the Windows 10 x64 debug platform

GfxInfo registers a shutdown observer to free the data, but only if the GfxInfo component was ever instantiated, and for the Windows GPU process that's only if WebRender is enabled (which, conveniently, it's not in my Windows VM with no “hardware” graphics acceleration, so I could reproduce this locally).

I have a patch that seems to work….

The severity field is not set for this bug.
:jgilbert, could you have a look please?

For more information, please visit auto_nag documentation.

https://hg.mozilla.org/mozilla-central/rev/4c642b2c5e88
https://hg.mozilla.org/mozilla-central/rev/488c511a3875
https://hg.mozilla.org/mozilla-central/rev/684350205020