User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/113.0

Steps to reproduce:

With Firefox Nightly 113, on a Wide Color Gamut monitor, open any website (eg GitHub) and look at the over-saturated color of UI elements such as buttons and banners. Compare these to Chrome or Safari on the same WCG monitor.

Relevant non-default config (has not changed, but may be needed to reproduce):

gfx.color_management.mode 1

Also I have had layout.css.more_color_4.enabled set to true for months, this is now the default in FF 113.

I suspect that gfx.color_management.native_srgb may be a culprit, but need to investigate further.

Actual results:

The sRGB colors are over saturated and the incorrect hue. sRGB green is a fully saturated WCG green, and so on. Chrome displays the colors correctly. Firefox Nightly used to display them correctly too, this is a recent regressions and I think it started from Nightly 113.

This also affects images with ICC profiles; it looks as if the images are converted to sRGB rather than to the monitor profile, and then the image data is thrown at the screen. Firefox used to do that, some years ago, but fixed it. So this is a regression.

I considered attaching a screen shot but t would need a WCG

Expected results:

Like previously, Firefox should display sRGB colors as sRGB.

Tiaan, probably fallout from your changes.

This is very likely, but I do not have the hardware to make a test of this. Screnshots would be very welcome.

@chris can i assist with something to get some screenshots?

Here is a screenshot (ICC profile is Prophoto colorspace) showing Chrome Canary 113 vs. Firefox Nightly 113 on my wide gamut Dell XPT 1720 laptop under Windows 11.

The screenshot was pasted into Photoshop, the monitor profile was assigned, then the colorspace changed to ProPhoto and exported as PNG with embedded color profile.

The page being displayed in both browsers is th ProPhoto test from https://svgees.us/PNG/iCCP/tests.html and the actual color patches are all in the sRGB gamut. Chrome is correctly applying the color profile and passing the test and displaying the colors correctly. Nightly is correctly applying the color profile, seems to assume the monitor is sRGB, then throws the values at the screen.

If I set gfx.color_management.native_srgb to false, close Nightly, and re-launch then Nightly displays the result correctly.

@Tiaan it occurs to me that this screenshot will look different (and perhaps the two look identical) on an sRGB screen. Let me know if I can help more.

In bug 1817641 the ToDeviceColor function was changed to convert colors
to sRGB first when converting to device colors. It seems this is not
valid, because it takes display mode into account, which might not be
sRGB.

Going over my changes, it looks like I converted to sRGB when I wasn't supposed to. This would mean p3 -> srgb -> srgb and that seems like it would cause over saturation.

Chris, could you attach your color settings? I have a similar laptop and I don't seem to be able to reproduce this on the latest nightly, see my settings for the current setup I have.

Also, looking at this, this seems to be saturating image colors, so it's unlikely to be due to Tiaan's changes (which affect CSS colors, not image colors).

Kelsey, this might be due to your HDR changes from bug 1799258?

Also, Chris, if you can repro this consistently it'd be great to get a regression range using mozregression (https://mozilla.github.io/mozregression/quickstart.html#gui)

My settings are similar to yours except HDR is off, and the display profile is an XYXLUT+matrix ICC profile measured from my screen, rather than the factory profile.

Here is the (original) SVG source for those PNG images. The colors are set using CSS like this

.blue_sky rect { fill: rgb(35.8614% 48.0665% 61.6556%)}

This bug has been marked as a regression. Setting status flag for Nightly to affected.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #10)

Also, Chris, if you can repro this consistently it'd be great to get a regression range using mozregression (https://mozilla.github.io/mozregression/quickstart.html#gui)

When my Nightly updated to 114 this came back.

In 113, setting gfx.color_management.native_srgb to false fixed it (for me; not for other affected users with default config).

That is still the value, but in 114 the over-saturated colors are back.

Chris, is there any chance you can help us confirm the regression range via the mozregression tool linked in comment 10? That would be very helpful :)

I can try. How do I download older Nightlies to find a known-good one? For example I would try the first Nightly 112.

If you're using the mozregression GUI tool, you can click the [S] button at the top to launch a single build for testing. Or you can just start a bisection run with something arbitrarily old and go from there (it'll launch that build for you to confirm it working correctly anyway).

Ah okay. I thought I needed a known-good date before starting.

(BTW Bugzilla is set to clear needinfo by default as soon as the person responds in any way, didn't intend to clear it before)

Ah okay. I thought I needed a known-good date before starting.

(BTW Bugzilla is set to clear needinfo by default as soon as the person responds in any way, didn't intend to clear it before)

I have exactly the same problem as Chris.

All was fine until today when I updated to 113 and my colors are way over-saturated on my Dell wide-gamut monitor.

Setting "gfx.color_management.native_srgb" to "False" corrected it like it was all the time before. Using an icc profile I created myself with an "i1 Photo Pro" calibrator.

Yep, this was from the pref flip in bug 1799258.
We shouldn't have flipped the pref there.

I'm duping this forward to bug 1832215, but thanks a lot for the work in here!