Can confirm that color management stopped working in Firefox 65 on the Mac (10.13.6). Upgraded tonight from the previous version of 64 and Firefox no longer works on my wide gamut monitor. All the colors are super saturated and all the tests besides the color profile ones fail on this page-

https://cameratico.com/tools/web-browser-color-management-test/

jco, can you find a regression window using mozregression? https://mozilla.github.io/mozregression/?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #9)

jco, can you find a regression window using mozregression? https://mozilla.github.io/mozregression/?

Jeff, I'm the author of the test linked above.

I can confirm the bug and the latest Nightly still shows it. Color management seems to be completely disabled for all untagged images and page elements, at least on the Mac, regardless of gfx.color_management.mode. Tagged images are rendered on the display gamut, independent of color profile. I've tried several combinations of the config settings and different monitor profiles.

This is something that happened between 64.02 and 65.0. I'll try the regression tool later today or tomorrow and then update this thread.

With this bug gong on, Firefox is almost unusable on wide gamut displays, such as most of Apple's current lineup. Everything looks super saturated.

Jeff,

mozregression narrowed the problematic version between:
6:32.63 INFO: Last good revision: e51037702c9e8febad9b39f219fec3f22a6d7f26
6:32.63 INFO: First bad revision: 22d335fc020fb0509c67c4a945db21a27b8332d4

The bug seems to have been triggered by changes on how Firefox relates to the Mac sandbox.
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e51037702c9e8febad9b39f219fec3f22a6d7f26&tochange=22d335fc020fb0509c67c4a945db21a27b8332d4

Here's the full log:
https://pastebin.com/FfaB9b0q

Problem happens as soon as I specify a monitor profile.

Working on a fresh profile with the only changers being:
gfx.color_management.display_profile: /Library/ColorSync/Profiles/Displays/Dell-3008WFP.icc
gfx.color_management.mode: 1

This is the display profile being used:
http://cameratico.com/tmp/Dell-3008WFP.icc

There's nothing special about it and I've tried with a few random profiles with the same results.

Please let me know if I can help any further.

I think I forgot to tag you on my reply, Jeff.

Ok. Great that regression window helps a lot. Haik, it looks like sandboxing broke our access to the system color profile. Can you help us toward a solution?

Can anyone who can reproduce this try changing security.sandbox.content.mac.earlyinit=false in about:config and restarting to see if that fixes the problem.

Also, can anyone reproduce the problem without manually setting gfx.color_management.display_profile?

Testing on 67.0a1 (2019-02-01) (64-bit):

• Changing security.sandbox.content.mac.earlyinit to false false fixes it.

• Removing the profile specified on gfx.color_management.display_profile also fixes the bug.

In both cases, color management seems to be working fine.

What is the expected behavior when there's no color profile specified on gfx.color_management.display_profile? Is Firefox able to use the system color profile for that display?

Yes. By default Firefox should just use the system color profile.

Jeff's fix makes it so that if the profile specified with gfx.color_management.display_profile is not accessible, we fall back to the system profile which will help because the system default will be better than the current fallback.

Due to the sandboxing changes in 65, profiles from /Library/ are not accessible in build 65+. I plan to land an additional fix allowing profiles from /Library/ColorSync/Profiles and ~/Library/ColorSync/Profiles to be used.

For now, if you need to use gfx.color_management.display_profile to select a non-default profile for Firefox, please try setting security.sandbox.content.mac.earlyinit=false (requires browser restart) as a workaround until we have the sandboxing issue fixed.

When the pref gfx.color_management.display_profile is used to load a color profile from the given path, the file is read from the filesystem in GetCMSOutputProfileData().

Before build 65, where we changed the Mac content sandbox to start earlier, GetCMSOutputProfileData() was run in content processes during startup before the content sandbox was enabled. With build 65, the sandbox is started earlier and, as a result, at the time GetCMSOutputProfileData() executes, sandbox filesystem restrictions are already enabled and prevent reading from /Library/ColorSync/Profiles. GetCMSOutputProfileData() is called in content processes during the handling of the SetXPCOMProcessAttributes message sent from the parent.

As a low risk solution, we can whitelist /Library/ColorSync/Profiles and ~/Library/ColorSync/Profiles in the content process sandbox. This will mean that, on Mac, gfx.color_management.display_profile should only be set to a profile that resides in one of

/Library/ColorSync/Profiles
~/Library/ColorSync/Profiles
/System/Library/ColorSync/Profiles

As a follow-up, we should whitelist the contents of the gfx.color_management.display_profile pref allowing color profiles to be used from anywhere on the filesystem that the user has access to. I will file a new bug to accomplish that.

Content process stack trace of GetCMSOutputProfileData():

* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0 XUL`gfxPlatform::GetCMSOutputProfileData() at gfxPlatform.cpp:2112
frame #1 XUL`gfxPlatform::CreateCMSOutputProfile() at gfxPlatform.cpp:2138
frame #2 XUL`gfxPlatform::Init() at gfxPlatform.cpp:1026
frame #3 XUL`gfxPlatform::InitChild() at gfxPlatform.cpp:511
frame #4 XUL`mozilla::dom::ContentChild::InitGraphicsDeviceData() at ContentChild.cpp:1159
frame #5 XUL`mozilla::dom::ContentChild::RecvSetXPCOMProcessAttributes() at ContentChild.cpp:598
frame #6 XUL`mozilla::dom::PContentChild::OnMessageReceived() at PContentChild.cpp:7750
frame #7 XUL`mozilla::dom::ContentChild::OnMessageReceived() at ContentChild.cpp:3558
frame #8 XUL`mozilla::ipc::MessageChannel::DispatchAsyncMessage() at MessageChannel.cpp:2160
frame #9 XUL`mozilla::ipc::MessageChannel::DispatchMessage() at MessageChannel.cpp:2087
frame #10 XUL`mozilla::ipc::MessageChannel::RunMessage() at MessageChannel.cpp:1936
frame #11 XUL`mozilla::ipc::MessageChannel::MessageTask::Run() at MessageChannel.cpp:1967
frame #12 XUL`nsThread::ProcessNextEvent() at nsThread.cpp:1161
frame #13 XUL`NS_ProcessNextEvent() at nsThreadUtils.cpp:474
frame #14 XUL`mozilla::ipc::MessagePump::Run() at MessagePump.cpp:88
frame #15 XUL`mozilla::ipc::MessagePumpForChildProcess::Run() at MessagePump.cpp:271
frame #16 XUL`MessageLoop::RunInternal() at message_loop.cc:315
frame #17 XUL`MessageLoop::RunHandler() at message_loop.cc:308
frame #18 XUL`MessageLoop::Run() at message_loop.cc:290
frame #19 XUL`nsBaseAppShell::Run() at nsBaseAppShell.cpp:137
frame #20 XUL`nsAppShell::Run() at nsAppShell.mm:702
frame #21 XUL`XRE_RunAppShell() at nsEmbedFunctions.cpp:908
frame #22 XUL`mozilla::ipc::MessagePumpForChildProcess::Run() at MessagePump.cpp:238
frame #23 XUL`MessageLoop::RunInternal() at message_loop.cc:315
frame #24 XUL`MessageLoop::RunHandler() at message_loop.cc:308
frame #25 XUL`MessageLoop::Run() at message_loop.cc:290
frame #26 XUL`XRE_InitChildProcess() at nsEmbedFunctions.cpp:746
frame #27 XUL`mozilla::BootstrapImpl::XRE_InitChildProcess() at Bootstrap.cpp:61
frame #28 plugin-container`content_process_main() at plugin-container.cpp:49
frame #29 plugin-container`main() at MozillaRuntimeMain.cpp:23
frame #30 libdyld.dylib`start()

Whitelist the /Library and ~/Library ColorSync profile directories allowing gfx.color_management.display_profile to be used to load color profiles from those locations.

The posted fix was tested on 10.14.3. I verified that the without the fix, setting gfx.color_management.display_profile to a file in the /Library or ~/Library ColorSync directories caused sandbox violations. With the fix, no errors were reported. I'll need some help verifying that the colors actually display correctly.

The posted fix was tested on 10.14.3. I verified that the without the fix, setting gfx.color_management.display_profile to a file in the /Library or ~/Library ColorSync directories caused sandbox violations. With the fix, no errors were reported. I'll need some help verifying that the colors actually display correctly.

I filed Bug 1524694 - "Fix gfx.color_management.display_profile for arbitrary profile paths" to restore the ability to use gfx.color_management.display_profile with a color profile from any directory.

https://hg.mozilla.org/mozilla-central/rev/5531999b1306

https://hg.mozilla.org/mozilla-central/rev/97f2cfdbba07

Hi reporter, can you please confirm that a current Nightly build works as expected again? We'd like to take this patch in a bugfix release and it would be nice to confirm that it was effective first :)

(In reply to Ryan VanderMeulen [:RyanVM] from comment #28)

Hi reporter, can you please confirm that a current Nightly build works as expected again? We'd like to take this patch in a bugfix release and it would be nice to confirm that it was effective first :)

It works perfectly well! :-)

Thanks!

Haik, please request Beta and Release approval when you get a chance. Not sure if we just one or both patches?

(In reply to Ryan VanderMeulen [:RyanVM] from comment #30)

Thanks!

Haik, please request Beta and Release approval when you get a chance. Not sure if we just one or both patches?

nightly -> works!

and...I am not sure it is patched...

beta 66.0b4 -> seems not works :-(

That's the expected result. The patch hasn't been backported anywhere yet (per comment 30 where I asked the developer to make the request so we can do so).

Comment on attachment 9040774 [details] [diff] [review]
Fallback to the system profile if we can't read the file for the profile.

Beta/Release Uplift Approval Request

Feature/Bug causing the regression

Bug 1501126

User impact if declined

We fallback to sRGB instead of the system profile if we can't read the profile specified in gfx.color_management.display_profile

Is this code covered by automated tests?

No

Has the fix been verified in Nightly?

Yes

Needs manual test from QE?

No

If yes, steps to reproduce

List of other uplifts needed

None

Risk to taking this patch

Low

Why is the change risky/not risky? (and alternatives if risky)

This is pretty low risk. It basically just gives us better defaults in the case of failure

String changes made/needed

Comment on attachment 9040822 [details]
Bug 1506495 - Whitelist /Library and ~/Library ColorSync Profile directories r?Alex_Gaynor

Beta/Release Uplift Approval Request

Feature/Bug causing the regression

Bug 1501126

User impact if declined

Users that use the gfx.color_management.display_profile setting in about:config to select a color profile will not get the correct colors. i.e., the selected color profile won't be used and Firefox will fallback a different color profile.

The fix allows gfx.color_management.display_profile to work as expected again for color profiles in

/Library/ColorSync/Profiles
~/Library/ColorSync/Profiles

In addition to /System/Library/ColorSync/Profiles which was not impacted by this bug.

Is this code covered by automated tests?

No

Has the fix been verified in Nightly?

Yes

Needs manual test from QE?

Yes

If yes, steps to reproduce

See the description of this bug. Use a color profile in /Library/ColorSync/Profiles or ~/Library/ColorSync/Profiles and confirm the profile is not used without the fix, but is used when the fix is applied.

List of other uplifts needed

None

Risk to taking this patch

Low

Why is the change risky/not risky? (and alternatives if risky)

The change only adds additional read-access paths to the Mac content process sandbox.

String changes made/needed

None

Comment on attachment 9040822 [details]
Bug 1506495 - Whitelist /Library and ~/Library ColorSync Profile directories r?Alex_Gaynor

Let's not forget part 2. OK to uplift for beta 5.

https://hg.mozilla.org/releases/mozilla-beta/rev/63b220f22add
https://hg.mozilla.org/releases/mozilla-beta/rev/864ba4d03156

It looks like that I'm having hard times confirming this fix on macOS 10.14 and 10.13. On my end the profile colors are not used neither on a supposed fixed build (latest Nightly 67.0a1) nor on a build that was unaffected (tried on ESR 60.5.0). I cannot seem to see any difference if setting the profile from /Library/ColorSync/Profiles/.

If anyone has a test case to test this against, I will be happy to give it another try.

Hi aiemaboy, I see that you've already confirmed this fix on Nightly in comment 29; would you mind helping us to verify this fix on 66 Beta [1] as well? Thank you!

[1] https://archive.mozilla.org/pub/firefox/candidates/66.0b5-candidates/

(In reply to Ciprian Georgiu [:ciprian_georgiu], Release Desktop QA from comment #38)

It looks like that I'm having hard times confirming this fix on macOS 10.14 and 10.13. On my end the profile colors are not used neither on a supposed fixed build (latest Nightly 67.0a1) nor on a build that was unaffected (tried on ESR 60.5.0). I cannot seem to see any difference if setting the profile from /Library/ColorSync/Profiles/.

If anyone has a test case to test this against, I will be happy to give it another try.

Hi aiemaboy, I see that you've already confirmed this fix on Nightly in comment 29; would you mind helping us to verify this fix on 66 Beta [1] as well? Thank you!

[1] https://archive.mozilla.org/pub/firefox/candidates/66.0b5-candidates/

It works very well just like Nightly. Thank you! 👍

Great to hear that :). Thanks for confirming!

Marking this as verified fixed per comment 39 and comment 29.

(In reply to aiemaboy from comment #39)

It works very well just like Nightly. Thank you! 👍

aiemaboy, one more thing, I just want to make sure you don't have the workaround still enabled (if you ever enabled it). Could you confirm that security.sandbox.content.mac.earlyinit = true in about:config.

Thank you!

(In reply to Haik Aftandilian [:haik] from comment #41)

(In reply to aiemaboy from comment #39)

It works very well just like Nightly. Thank you! 👍

aiemaboy, one more thing, I just want to make sure you don't have the workaround still enabled (if you ever enabled it). Could you confirm that security.sandbox.content.mac.earlyinit = true in about:config.

Thank you!

Oh, I didn't touch anything in that(about:config).

https://www.dropbox.com/s/twt79cbjz0jsbmf/sandbox.png

Is this right?

(In reply to aiemaboy from comment #42)

Oh, I didn't touch anything in that(about:config).

https://www.dropbox.com/s/twt79cbjz0jsbmf/sandbox.png

Is this right?

Yes, that's right. Great! Thanks again for verifying the fix.

Just double checked it for you.

security.sandbox.content.mac.earlyinit = true (default)
gfx.color_management.display_profile = /Library/ColorSync/Profiles/Displays/Dell-3008WFP.icc
gfx.color_management.enablev4 = true
gfx.color_management.mode = 1

65.0 and 67.0a1 (2019-02-01)
Broken, as expected

66.0b5 and 67.0a1 (2019-02-07)
Fixed, as described here

By the way, thank you all for the fast response and fix.

https://hg.mozilla.org/releases/mozilla-release/rev/14dfa47c99a1
https://hg.mozilla.org/releases/mozilla-release/rev/82226e47f0f7

Hi aiemaboy,

Could you please do us another small favor in helping us to confirm the fix, but this time on Firefox 65.0.1? Just to make sure that everything works as expected in that build as well. Thank you (and I apologize if creating any hassle for you)!

(In reply to Ciprian Georgiu [:ciprian_georgiu], Release Desktop QA from comment #47)

Hi aiemaboy,

Could you please do us another small favor in helping us to confirm the fix, but this time on Firefox 65.0.1? Just to make sure that everything works as expected in that build as well. Thank you (and I apologize if creating any hassle for you)!

I am totally fine. :-) And it works well! 👌

(In reply to aiemaboy from comment #48)

I am totally fine. :-) And it works well! 👌

Thank you! :)

Installed latest Firefox version 65.0.1, still getting oversaturated colours on my MacBook Pro late 2016. Do I need to mess with the settings in about:config to enable this?

Hi Bacon,

(In reply to Bacon Lightning from comment #50)

Installed latest Firefox version 65.0.1, still getting oversaturated colours on my MacBook Pro late 2016. Do I need to mess with the settings in about:config to enable this?

If you haven't already changed any color management settings in about:config, you shouldn't be affected by this bug.

If colors are not looking right, you can try turning on full color management and optionally set a color profile. The settings you need to change are documented here: ICC color correction in Firefox.

If you end up setting a color profile, it needs to be in one of the following directories.

• /Library/ColorSync/Profiles
• ~/Library/ColorSync/Profiles
• /System/Library/ColorSync/Profiles

Bug 1524694 is to make them work when installed in any directory.