User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

Firefox 91 changed color management. Testet in MX Linux XFCE and Manjaro KDE colors are too saturated (Wide Gamut Monitor) .
Profile added in gfx.color... resulted in correct results.
In Mint and Ubuntu same procedure did not correct the issue.

Actual results:

too saturated colors in wide gamut monitor

Expected results:

correct color display. Firefox should read the ICC profile correctly from operating system.

The Bugbug bot thinks this bug should belong to the 'Core::GFX: Color Management' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Can you post your about support and maybe include a screenshot showing the issue?

Can you also attach your display profile to the bug?

This is my about...
color management works fine in Windows 10 without mentioning the profile in the about section. The profile is of course installed in windows.

In Linux Manjaro KDE and Linux MX Xfce it used to be the same. Now (91) color management only works after mentioning the profile in the about section.

In Linux Mint cinnamon and in Linux Ubuntu KDE mentioning the profile in the about section has no effect. Colors are shown too saturated.

You should also be able to use mozregression to find the change that caused the breakage.

This is a test with color profile installed in the about section on Linux MX. The page is: https://fotovideotec.de/browser_farbmanagement/farb-testbilder.html

In Linux Mint and Ubuntu all colors are like the "wide gamut" column regardless of color profile mentioned or not in the about section.

This is the profile I am using. The long file name is not the problem. I tried to rename it few letters without spaces etc.

After I upgraded to Firefox 91 on my Ubuntu 20.04 LTS, I also noticed that the colors were too saturated. I did not touch any settings, just preformed an upgrade of Firefox.
Here is the same image in "Gimp", "Gnome Image Viewer" and "Firefox" side by side: https://www.dropbox.com/s/3aag1qck3my6cz3/Firefox91.png?dl=0 The image was developed and exported from Darktable. The original looked the same in Darktable as in Gimp and Image Viewer.
If you want to view/download the image and all it's Exif data: https://www.dropbox.com/s/swftpee2tsdinnk/_DSC0461.jpg?dl=0

However, if I visit sites like https://cameratico.com/tools/web-browser-color-management-test/ and https://photographylife.com/is-your-browser-color-managed they all agree that my Firefox is Color managed.

As a workaround, when setting an icc profile manually using "gfx.color_management.display_profile" the color management is restored. However, when using the snap version of firefox this only works when the icc profile is located in the ~/snap/firefox folder (or another location that has access permissions set through snap).

I am using the installed version of firefox in Mint 19.4 (based on Ubuntu 20.04) and in Kubuntu 21.04, both up to date. The workaround does not work.
I am also using Manjaro KDE and MX XFCE both up to date. The workaround works. I think I mentioned that above. Maybe was not quite clear. English is not my native language.
I have not tried the snap or flatpak versions.

Just found out, that Mint and Ubuntu work as Manjaro and MX. You just have to insert the profile with complete path in the line gfx_color_display_profile. Then colors and saturation are correct. My mistake was, that the profiles are stored in different addresses in various linux distributions.

That still means, that the profile must be referenced in firefox. It is not enough that the profile is installed in the OS.

Me too.

I use the following to load the profile. I am currently on 92.0b9 on the arch developer package and noticed the issue in the last week. Chrome still uses the correct colour profile automatically, Firefox now needs the colour profile specified in the settings, ie, the workaround described above does work for me, but I am concerned this setting might get synced.

xcalib -d :0 -s 0 downloads/Y2XND-LQ156D1\ #1\ 2017-11-30\ 21-27\ 2.2\ F-S\ XYZLUT+MTX.icm 
dispwin -I -d 1 ~/downloads/Y2XND-LQ156D1\ #1\ 2017-11-30\ 21-27\ 2.2\ F-S\ XYZLUT+MTX.icm

Jamie, can you try to find a regression window using mozregression?

@Jeff

12:38.92 INFO: No more integration revisions, bisection finished.
12:38.92 INFO: Last good revision: a83914c4bef76a513c2036911355389f7e9edae8
12:38.92 INFO: First bad revision: c49de061c1fab19f934574e959938c5500d1d080
12:38.92 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a83914c4bef76a513c2036911355389f7e9edae8&tochange=c49de061c1fab19f934574e959938c5500d1d080

Jed, it looks like your work in bug 1635451 broke this. Can you take a look? We try to get the profile here: https://searchfox.org/mozilla-central/rev/ad2ffab089e4e0c0fe99a1a046ab2b1c45546bdb/gfx/thebes/gfxPlatformGtk.cpp#490

[Tracking Requested - why for this release]:

Confirming due to multiple reports, successful bisection and the code unfortunately making sense wrt to the breakage.

It looks like we had a similar issue on Windows with win32k lockdown, fixed in bug 1540776, so we might already have most of a solution for this.

Notes for reproducing this bug (if not already using a color profile): it's necessary to install the profile with dispwin -I, not dispwin without that flag or with xcalib; those will tell the X server to adjust the colors displayed but won't set the _ICC_PROFILE root window property that Firefox is looking for. (dispwin is from the Argyll CMS package.)

Also, I notice that we have fallback code to derive a profile from the EDID data, and I notice that it doesn't work with the monitor I'm using, because it requires the blob to be exactly 128 bytes, which is unnecessarily incompatible with EDID 1.3 or newer (so, probably most monitors still in use in 2021). But that's a separate bug.

(In reply to Jed Davis [:jld] ⟨⏰|UTC-6⟩ ⟦he/him⟧ from comment #20)

Also, I notice that we have fallback code to derive a profile from the EDID data, and I notice that it doesn't work with the monitor I'm using, because it requires the blob to be exactly 128 bytes, which is unnecessarily incompatible with EDID 1.3 or newer (so, probably most monitors still in use in 2021). But that's a separate bug.

Actually, this wouldn't be used even if it did work; see bug 1696819.

(In reply to Jed Davis [:jld] ⟨⏰|UTC-6⟩ ⟦he/him⟧ from comment #20)

Notes for reproducing this bug (if not already using a color profile): it's necessary to install the profile with dispwin -I, not dispwin without that flag or with xcalib; those will tell the X server to adjust the colors displayed but won't set the _ICC_PROFILE root window property that Firefox is looking for. (dispwin is from the Argyll CMS package.)

Does that mean that workarounds would include setting _ICC_PROFILE manually and/or setting the profile with dispwin -I and dispwin?

Thanks

Does that mean that workarounds would include setting _ICC_PROFILE manually and/or setting the profile with dispwin -I and dispwin?

The workaround would be (temporarily) flipping dom.ipc.avoid-gtk to false until we can get a fix out. We're missing the code to remote the color profile if we don't allow direct connections to X, so fiddling with the environment or color profile itself probably won't resolve that.

(In reply to Gian-Carlo Pascutto [:gcp] from comment #23)

Does that mean that workarounds would include setting _ICC_PROFILE manually and/or setting the profile with dispwin -I and dispwin?

The workaround would be (temporarily) flipping dom.ipc.avoid-gtk to false until we can get a fix out. We're missing the code to remote the color profile if we don't allow direct connections to X, so fiddling with the environment or color profile itself probably won't resolve that.

That workaround doesn't seem to work properly. It is doing something, since https://webkit.org/blog-files/color-gamut/comparison.html shows a difference between the sRGB and P3 versions, but the sRGB version is still super saturated.

Also moving the firefox window to a different monitor doesn't seem to affect the colour rendering (I have a wide-gamut monitor as my primary and an sRGB gamut one as my secondary; both are colour calibrated with DisplayCal, and for example loading up the P3 version in darktable clearly shows differences as I move the window between monitors).

Cheers

David

Previously, content processes would try to contact the X server
directly during startup to read color calibration information; with
dom.ipc.avoid-gtk this doesn't work because the process is in headless
mode. This patch extends the color profile IPC facility added in bug
1540776 for Windows sandboxing (win32k lockdown) to GTK under X11.
(Currently there's no support for color management under Wayland, so
there's nothing for this patch to fix in that case.)

That workaround doesn't seem to work properly.

That's unexpected. Does your testcase work correctly with Firefox 90?

(In reply to Gian-Carlo Pascutto [:gcp] from comment #26)

That workaround doesn't seem to work properly.

That's unexpected. Does your testcase work correctly with Firefox 90?

Well that is odd; it does not. Firefox 90.0.2 (just downloaded, and with a new profile) seems to be showing the P3 and Adobe RGB images correctly, but expanding sRGB images to full gamut. Weird. Chromium-browser does the "right thing".

Ahh! Actually, looking at a different page (https://cameratico.com/tools/web-browser-color-management-test/) I think I see the problem - it is expanding things which aren't tagged to full gamut, rather than interpreting them as sRGB which I understand is what it is supposed to be doing. Images which actually have an sRGB color profile set seem to be displayed correctly. And I've just confirmed this by taking an untagged image and tagging it with an sRGB icc profile, and the tagged version displays correctly, but the untagged version gets mapped to full gamut.

But I guess from your point of view, the important thing is that 90.0.2 is behaving the same as 91 with dom.ipc.avoid-gtk set to false.

Cheers

David

Alright, thanks for confirming! It looks like you found a different bug with another root cause. Do you want to file it separately?

(In reply to Gian-Carlo Pascutto [:gcp] from comment #28)

Alright, thanks for confirming! It looks like you found a different bug with another root cause. Do you want to file it separately?

I will file it as a separate issue. Thanks for your time!

Cheers

David

https://hg.mozilla.org/mozilla-central/rev/45206a6d152e

This bug has a low severity but a high priority, is that worth uplifting into beta? Thanks

This bug has a low severity but a high priority, is that worth uplifting into beta? Thanks

Bit late but: we don't expect this impacts a lot of users, but preferred to fix it now as it's a regression from a recent change and it's easier to fix if you still remember how :)

Is this something we should consider taking on ESR91?

Comment on attachment 9239415 [details]
Bug 1725573 - Add color profile remoting for GTK.

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Fixes a regression in color management support that shipped in 91.
• User impact if declined: Color-calibrated monitors on Linux won't respect color calibration.
• Fix Landed on Version: 94
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This is mostly code that we already shipped on Windows, and on Linux it's been stable so far on Nightly/Beta.
• String or UUID changes made by this patch: none

Comment on attachment 9239415 [details]
Bug 1725573 - Add color profile remoting for GTK.

Approved for 91.3esr.

https://hg.mozilla.org/releases/mozilla-esr91/rev/002d4a010c5a

@davidm Could you please help us with a check on Firefox 94.0 and Firefox 91.3 ESR builds? We are limited in the linux flavors availability and it seems that it may be dependent on a monitor component as well.

I can confirm that both 94.0 build 3 and 91.3 build 1 behave the same as 78.15.0esr, in that they render images tagged with a profile correctly.

Side not: I've also figured out what is going on in the untagged case; for some reason gfx.color_management.mode defaults to 2 (don't do colour management for untagged elements) rather than 1 (colour-manage everything untagged as sRGB as per https://www.w3.org/TR/css-color-4/#untagged)

It appears that way back around firefox 76(?) mode 1 was the default, it broke some websites, so it was set to 2 to fix that, and for one reason or another it has never been set back to the way the standard says it should be.

Cheers

David

Closing the issue as verified fixed based on comment 39.