1506495 - Color management seems to not working on Mac

Status: VERIFIED FIXED

(Core :: Graphics: Color Management, defect, P1)

Description

[aiemaboy]

Attachment: color.jpg

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

gfx.color_management.enablev4 = true
gfx.color_management.mode = 1
gfx.color_management.display_profile = /Library/ColorSync/Profiles/SyncMaster.icc


Actual results:

(attached image)

Firefox 64.0 = Safari 12 ≠ Firefox 65.0  


Expected results:

Color management seems to not work.

Comment 1

[Jeff Muizelaar [:jrmuizel]]

Is this is a regression with Firefox 65?

Comment 2

[aiemaboy]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #1)
> Is this is a regression with Firefox 65?

Yes.

Comment 3

[Jeff Muizelaar [:jrmuizel]]

Are you able to find a regression window using mozregression? https://mozilla.github.io/mozregression/

Comment 4

[aiemaboy]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #3)
> Are you able to find a regression window using mozregression?
> https://mozilla.github.io/mozregression/

I'm... stuck in installation(mozregression) process...this is very difficult for me to do. :-(

Comment 5

[Jeff Muizelaar [:jrmuizel]]

What goes wrong?

Comment 6

[aiemaboy]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #5)
> What goes wrong?

Because I do not know anything about python...

Comment 7

[aiemaboy]

(In reply to aiemaboy from comment #6)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #5)
> > What goes wrong?
> 
> Because I do not know anything about python...

I do not know how to use this on my Mac.

Comment 8

[jco]

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/

Comment 9

[Jeff Muizelaar [:jrmuizel]]

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

Comment 10

[Fábio Pili]

(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.

Comment 11

[Fábio Pili]

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.

Comment 12

[Fábio Pili]

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

Comment 13

[Jeff Muizelaar [:jrmuizel]]

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?

Comment 14

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 15

[Jeff Muizelaar [:jrmuizel]]

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

Comment 16

[Jeff Muizelaar [:jrmuizel]]

Attachment: Fallback to the system profile if we can't read the file for the profile.

Comment 17

[Fábio Pili]

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?

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/97f2cfdbba07
Fallback to the system profile if we can't read the file for the profile. r=aosmond

Comment 19

[Jeff Muizelaar [:jrmuizel]]

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

Comment 20

[Haik Aftandilian [:haik]]

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.

Comment 21

[Haik Aftandilian [:haik]]

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()

Comment 22

[Haik Aftandilian [:haik]]

Attachment: Bug 1506495 - Whitelist /Library and ~/Library ColorSync Profile directories r?Alex_Gaynor

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

Comment 23

[Haik Aftandilian [:haik]]

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.

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5531999b1306
Whitelist /Library and ~/Library ColorSync Profile directories r=Alex_Gaynor

Comment 25

[Haik Aftandilian [:haik]]

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.

Comment 26

[Daniel Varga [:dvarga]]

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

Comment 27

[Daniel Varga [:dvarga]]

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

Comment 28

[Ryan VanderMeulen [:RyanVM]]

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 :)

Comment 29

[aiemaboy]

(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! :-)

Comment 30

[Ryan VanderMeulen [:RyanVM]]

Thanks!

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

Comment 31

[aiemaboy]

(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 :-(

Comment 32

[Ryan VanderMeulen [:RyanVM]]

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 33

[Jeff Muizelaar [:jrmuizel]]

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 34

[Liz Henry (:lizzard) (relman/hg->git project)]

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

Fix for regression, verified in nightly.
Let's uplift for beta 5.

Comment 35

[Haik Aftandilian [:haik]]

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 36

[Liz Henry (:lizzard) (relman/hg->git project)]

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.

Comment 37

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

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

Comment 38

[Ciprian Georgiu, Desktop QA]

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/

Comment 39

[aiemaboy]

(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! 👍

Comment 40

[Ciprian Georgiu, Desktop QA]

Great to hear that :). Thanks for confirming!

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

Comment 41

[Haik Aftandilian [:haik]]

(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!

Comment 42

[aiemaboy]

(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?

Comment 43

[Haik Aftandilian [:haik]]

(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.

Comment 44

[Fábio Pili]

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.

Comment 45

[Ryan VanderMeulen [:RyanVM]]

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

[Triage Comment]
Fixes broken color management on macOS due to sandboxing changes in Fx65. Approved for 65.0.1 (shipping early next week).

Comment 46

[Ryan VanderMeulen [:RyanVM]]

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

Comment 47

[Ciprian Georgiu, Desktop QA]

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)!

Comment 48

[aiemaboy]

(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! 👌

Comment 49

[Ciprian Georgiu, Desktop QA]

(In reply to aiemaboy from comment #48)

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

Thank you! :)

Comment 50

[Bacon Lightning]

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?

Comment 51

[Haik Aftandilian [:haik]]

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.