Color management seems to not working on Mac

VERIFIED FIXED in Firefox 65
(NeedInfo from)

Status

()

defect
P1
normal
VERIFIED FIXED
6 months ago
3 months ago

People

(Reporter: aiemaboy, Assigned: haik, NeedInfo)

Tracking

(Depends on 1 bug, {regression})

65 Branch
mozilla67
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(relnote-firefox 65+, firefox-esr60 unaffected, firefox65+ verified, firefox66+ verified, firefox67+ verified)

Details

Attachments

(3 attachments)

Reporter

Description

6 months ago
Posted image 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.
Component: Untriaged → GFX: Color Management
Product: Firefox → Core
Is this is a regression with Firefox 65?
Flags: needinfo?(aiemaboy)
Reporter

Comment 2

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

Yes.
Flags: needinfo?(aiemaboy)
Are you able to find a regression window using mozregression? https://mozilla.github.io/mozregression/
Reporter

Comment 4

6 months ago
(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. :-(
What goes wrong?
Depends on: 1425105
Reporter

Comment 6

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

Because I do not know anything about python...
Reporter

Comment 7

6 months ago
(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.
Priority: -- → P3

Comment 8

4 months ago

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

Flags: needinfo?(jco)

Comment 10

4 months ago

(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

4 months ago

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

4 months ago

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

Flags: needinfo?(jmuizelaar)
Blocks: 1501126
Flags: needinfo?(jmuizelaar)

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?

Flags: needinfo?(haftandilian)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Priority: P3 → P1
Summary: Color management seems to not working → Color management seems to not working on Mac

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.

Assignee

Updated

4 months ago
Assignee: nobody → haftandilian
Flags: needinfo?(haftandilian)
Flags: needinfo?(fabio)

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

Attachment #9040774 - Flags: review?(aosmond)
Attachment #9040774 - Flags: review?(aosmond) → review+

Comment 17

4 months ago

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?

Flags: needinfo?(fabio)

Comment 18

4 months ago
Pushed by jmuizelaar@mozilla.com:
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

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

Assignee

Comment 20

4 months ago

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.

Assignee

Comment 21

4 months ago

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

Comment 22

4 months ago

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

Assignee

Comment 23

4 months ago

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

4 months ago
Pushed by haftandilian@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5531999b1306
Whitelist /Library and ~/Library ColorSync Profile directories r=Alex_Gaynor
Assignee

Comment 25

4 months ago

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.

Assignee

Updated

4 months ago
See Also: → 1524694
Assignee

Updated

4 months ago
See Also: → 1524722

Comment 26

4 months ago
bugherder
Status: NEW → RESOLVED
Last Resolved: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67

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

Reporter

Comment 29

4 months ago

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

Flags: needinfo?(aiemaboy)

Thanks!

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

Flags: needinfo?(haftandilian)
Reporter

Comment 31

4 months ago

(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

Attachment #9040774 - Flags: approval-mozilla-release?
Attachment #9040774 - Flags: approval-mozilla-beta?
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.
Attachment #9040774 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Assignee

Comment 35

4 months ago

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

Flags: needinfo?(haftandilian)
Attachment #9040822 - Flags: approval-mozilla-release?
Attachment #9040822 - Flags: approval-mozilla-beta?

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.

Attachment #9040822 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: qe-verify+
Whiteboard: [qa-triaged]

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/

Flags: needinfo?(aiemaboy)
Reporter

Comment 39

3 months ago

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

Flags: needinfo?(aiemaboy)

Great to hear that :). Thanks for confirming!

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

Status: RESOLVED → VERIFIED
Flags: qe-verify+
Assignee

Comment 41

3 months ago

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

Assignee

Updated

3 months ago
Flags: needinfo?(aiemaboy)
Reporter

Comment 42

3 months ago

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

Flags: needinfo?(aiemaboy)
Assignee

Comment 43

3 months ago

(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

3 months ago

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.

Flags: qe-verify+
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).
Attachment #9040774 - Flags: approval-mozilla-release? → approval-mozilla-release+
Attachment #9040822 - Flags: approval-mozilla-release? → approval-mozilla-release+

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

Flags: needinfo?(aiemaboy)
Reporter

Comment 48

3 months ago

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

Flags: needinfo?(aiemaboy)

(In reply to aiemaboy from comment #48)

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

Thank you! :)

Flags: qe-verify+

Comment 50

3 months ago

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?

Assignee

Comment 51

3 months ago

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.

QA Whiteboard: [qa-triaged]
Whiteboard: [qa-triaged]
You need to log in before you can comment on or make changes to this bug.