This api use needs to move to parent.

Depends on D25810

Depends on D25811

I will try to get to this tomorrow.

Currently, the GetCMSOutputProfile() and related methods pass their output
using the old C-style "ptr, len" parameters. This makes them more difficult
to deal with later in this change when they need to be safely passed over IPC.

This refactors them to return nsTArray<uint8_t> results instead. I also
removed some old cruft, refactored the code, and fixed a bug that has gone
unnoticed for a long time.

This change is needed for Win32k lowndown. I have the refactoring change above, and I will add the color profile code shortly.

https://hg.mozilla.org/mozilla-central/rev/504aca5e5357

Oops - Forgot to set as leave-open. There's a few more changes on their way for this.

In the content process, Windows won't perform any of the common logic for
CMS profile loading anymore. That means that it is no longer "common logic",
and that profile loading is now always platform-specific.

This change refactors out the "common logic" into a callable function that
the platform-specific functions can call if they want to. Soon, the Windows
logic won't call it in the content process.

Once Win32k lockdown is enabled, we can't call GetICMProfileW() in the child,
nor can we access whatever arbitrary file
"gfx.color_management.display_profile" points to.

As a result, we must collect the data from these files in the parent process
and pass it to child.

Depends on D64674

For Win32k lockdown, we need to remove the content processes' ability to
call GetICMProfileW(). Since it needs this to retrieve the output color
profile, a new synchronous call is added that allows it to request the
parent process to read this file on its behalf.

The contents of the file are now being cached as well, as this should help
ease some of the increased parent process I/O caused by the children not
being able to do this in their process anymore.

Does every child do this (e.g. as part of its gfxPlatform initialization), or is it done only on-demand (and if so, how common is that)? I'm wondering because of the risk that the request to the parent could block for a considerable length of time if the parent process is busy.

(In reply to Jonathan Kew (:jfkthame) from comment #16)

Does every child do this (e.g. as part of its gfxPlatform initialization), or is it done only on-demand (and if so, how common is that)? I'm wondering because of the risk that the request to the parent could block for a considerable length of time if the parent process is busy.

You're right that this is done by every child process as part of gfxPlatform initialization, and whenever a pref update forces a reload of the color profile. In normal circumstances, that's once per child process. The main motivation for this message existing is the possibility of a pref change forcing a reload.

I'm concerned, then, that we might run into the same issue as we had with the system font list on Android, and recently fixed in bug 1620111. Basically, we were using a sync IPC message to get the list of the fonts from the parent process, but this could cause child startup to block for hundreds of milliseconds if the parent was busy at that time. So we just removed that sync message and instead of "pulling" the data by sending a message back to the parent during child startup -- which the parent might not respond to for some time -- we instead "push" the data as part of the XPCOMProcessAttributes message when launching the child.

Having just eliminated that blocking message from child-process startup, it seems unfortunate to introduce a new one which may suffer from the same issue and reintroduce similar child-startup delay. Could we instead attach the color profile data to the process-attributes message, and avoid the extra sync-ipc round-trip?

Backed out changeset 18c3c5e79f1c for causing xpcshell failures in test_BHRObserver.js

Backout link: https://hg.mozilla.org/integration/autoland/rev/17adc9cb1db942af888d6db8ed5141dde2d8a1e9

Push with failures: https://treeherder.mozilla.org/?#/jobs?repo=autoland&group_state=expanded&searchStr=windows%2C10%2Cx64%2Cshippable%2Copt%2Cxpcshell%2Ctests%2Ctest-windows10-64-shippable%2Fopt-xpcshell-e10s-1%2Cx%28x1%29&tochange=18c3c5e79f1c121f29e851362ec19831e8d5f82f&fromchange=d72cc8e3d9496e2b4dbc4e98800d0c25463e0c37&selectedJob=293407452

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

Updated review to address the issue brought up by :jfkthame, and also fix this XPCShell timeout failure

Backed out for build bustages and perma failures.

Push with failure: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=pending%2Crunning%2Csuccess%2Ctestfailed%2Cbusted%2Cexception&searchStr=linux%2Cx64%2Cdebug%2Cbuild-linux64%2Fdebug%2C%28b%29&revision=8b091426bc102a132d665e967da50f870f1893fa&selectedJob=294872536

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=294872536&repo=autoland&lineNumber=3900
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=294876738&repo=autoland&lineNumber=575

Backout: https://hg.mozilla.org/integration/autoland/rev/3d5fa5fe3e1417a3812d9211ac93ab617a061c46

Investigating - Will likely need a slight refactor.

https://hg.mozilla.org/mozilla-central/rev/9087564e9fea

Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.