User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0 Screenshot: http://www.grabup.com/uploads/6234709b6258342c6cc4480e6d3f2712.png This issue has plagued me since FF3 RC2, when suddenly, it turned that orange/red color. Any attempts to reboot FF, or reinstall with new versions (RC3, 3.0) have not been successful. Reproducible: Always Steps to Reproduce: 1. Default FF window exhibits problem. Actual Results: All windows experience this issue (including preferences). Expected Results: All windows experience this issue (including preferences).

Shawn and Chris: I remember discussing this problem with one of you on IRC sometime in the last 2-3 months. I've never been able to reproduce it myself. Whichever of you it was, please chime in :-)

I was in the discussion, but Chris was the one who was seeing it.

The bug you're probably thinking of is bug 403169 comment 39 et seq.

Chris (since you've now told me you're the one who's also seen this problem), it might help for you to compare your software/hardware setup with that of the reporter, in the hope that you'll find clues about what causes this problem.

What additional details aside from those provided in the user agent string (Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0) would be beneficial to you?

I haven't a clue. Chris may be able to help you. As far as I know he's the only other one who's ever seen this problem.

Comment 44 in the other bug is yet another report of this same thing. It's pretty clear that colour management is still being applied to window chrome somehow. What *isn't* clear from the discussion over there is whether this is supposed to happen. I'm confirming this for further investigation, since I can easily reproduce it with a fresh profile and gfx.color_management.enabled set to true. Regression because it didn't always happen. I believe RC2 (or whatever was current around the time of my first comment there, on 02 May 2008) is where I first saw the problem as well.

(In reply to comment #7) > Regression because it didn't always happen. I believe RC2 (or whatever was > current around the time of my first comment there, on 02 May 2008) is where I > first saw the problem as well. Chris, could you possibly verify if you can see this bug with a build _before_ bug 429915 landed ? (landed 2008-04-28). I don't see the bug discussed here, can't test it.

Happens in Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008042704 Minefield/3.0pre as well. I don't have time to chase the regression range any further back than that right now, but I might be able to next week.

My bug was declared a dupe of this, and I've got a decent test case: Steps to Reproduce: 1. Set gfx.color_management.enabled to False 2. Restart Firefox 3. Run a google search 4. Note the relatively pure blue the search result links display as 5. Set gfx.color_management.enabled to True 6. Restart Firefox 7. Run a google search 8. Note how the color of the search result links has shifted dramatically towards purple Actual Results: The blue color has been shifted towards purple. If you create that same color in a color-management-aware application such as Adobe Photoshop (by extracting the hex value for the color from the CSS), the color will match Firefox when gfx.color_management.enabled is set to False, proving that the color Firefox is rendering when gfx.color_management.enabled is set to True is wrong. Expected Results: Firefox should display blue colors as blue, without a shift towards purple, matching the colors rendered by color-management-aware applications such as Adobe Photoshop and Safari. Results seen on a MacBook Pro LCD screen with a calibrated custom profile for this specific display. In the specific example of Google, I'm talking about Unvisited links. I am aware that Visited links become purple, but that is NOT what I am talking about. Additionally, while setting gfx.color_management.enabled to True improves the overall color accuracy of images displayed in Firefox, the blue problem also afflicts jpgs. It was just easiest to give you guys the text example since everyone should be able to see that.

Ty, your bug should not have been marked as a dupe of this one. This bug is about window chrome (UI elements), not page content.

That's what I said to the person who marked it as a dupe, thanks for unduping it.

I'm also not able to see this bug with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9pre) Gecko/2008061004 Minefield/3.0pre ID:2008061004. If anyone can try to find the real regression range it would be very helpful. Thanks!

Chris - Can you cofirm that you can repro this issue with the latest nightlies? I've heard talk of this bug (had to do with hardcoded CSS colors for the firefox mac imitation chrome), but people seem to be saying that a fix landed. I'd like to know if it's still a blocker for CM.

(In reply to comment #15) > Chris - Can you cofirm that you can repro this issue with the latest nightlies? > I've heard talk of this bug (had to do with hardcoded CSS colors for the > firefox mac imitation chrome), but people seem to be saying that a fix landed. What fix would this be? Is there some other bug that had bearing on this that I didn't know about?

(In reply to comment #11) > My bug was declared a dupe of this, and I've got a decent test case: > > Steps to Reproduce: > 1. Set gfx.color_management.enabled to False In latest Minefield, set gfx.color_management.mode to 0 > 2. Restart Firefox > 3. Run a google search > 4. Note the relatively pure blue the search result links display as > 5. Set gfx.color_management.enabled to True Set gfx.color_management.mode to 1 > 6. Restart Firefox > 7. Run a google search > 8. Note how the color of the search result links has shifted dramatically > towards purple > Actual Results: > The blue color has been shifted towards purple. What have you got in the gfx.color_management.display_profile string? In some other bug reports, color shifting has turned out to be due to a bad display_profile.

gfx.color_management.display_profile is blank in Fx 3 that exhibits this bug on my machine. I'm not sure *why* it's blank; I have a perfectly valid profile set up on my machine, but Firefox obviously isn't reading it properly. I still don't think that's at the root of the problem here, though. This bug is about colour management being applied to window chrome, and my contention is that it shouldn't be (or should be *consistently* applied, which it isn't either), based on discussion I've seen in other bugs where it seemed that this was not the developers' intention. Having bad profile data and having colour management applied to window chrome at all are orthogonal issues. A blank profile string is very easy to detect and ignore, yes, but that doesn't solve the problem this bug is about.

As mentioned in bug 450283, the system is queried for the display profile if the display_profile string is blank. In response to a question that I believe was never answered - yes, color management should be applied to the window chrome (color management happens at gfx draw time, and so it affect the xul rendering engine too). Color management is supposed to let us render the pixels more accurately, so it makes sense to do it everywhere we can. Chris - You say that color management isn't consistently applied. Can you elaborate? The only areas that shouldn't be color corrected are a few places where we use the OS to draw native widgets (like the window control buttons in the top left and the scroll bar). This isn't something we can fix, since we don't control the drawing. Can you also clarify whether the colors are wrong _just_ for the window chrome or if they're off for the page as well? If it's just the chrome, then it should have been fixed with whatever changeset landed the stuff that got rid of hardcoded CSS colors in the mac imitation chrome (vlad - do you know what this might be?) If the problem happens for all rendering, then it's an issue with your display profile, and you should either calibrate it with ColorSync or download an ICC profile matching your display.

(In reply to comment #19) > In response to a question that I believe was never answered - yes, color > management should be applied to the window chrome (color management happens at > gfx draw time, and so it affect the xul rendering engine too). Color management > is supposed to let us render the pixels more accurately, so it makes sense to > do it everywhere we can. Yes, but this can result in window chrome that looks totally different from other, native apps. I don't know if it's because the colour corrections are being applied twice (once by the Mac OS and once by Firefox) or if it's due to some other reason, but Firefox 3 window chrome definitely matches the rest of the OS better with colour management turned off on my machine. > Chris - You say that color management isn't consistently applied. Can you > elaborate? The only areas that shouldn't be color corrected are a few places Most of this is over in bug 403169 comment 39 et seq. That whole bug is probably worth a read if you haven't yet. I have some screenshots posted over there for comparison purposes. For the record, the exact same screenshots *could* be taken with the latest release build of Firefox, but I haven't bothered re-taking them. There's very obviously a difference between the colour of the window titlebar and the rest of the toolbars, though. That's the clearest "inconsistency" I can see, although there is some kind of colour correction being applied to all the window chrome, as far as I can tell. > Can you also clarify whether the colors are wrong _just_ for the window chrome > or if they're off for the page as well? I'm not exactly sure how I'd test that, but if you'll explain how I could, I'd be more than happy to.

See also bug 439354, bug 449833 and bug 449832 where I change the toolbars and titlebar on Mac OS X not to be color corrected by using "native theming" for them. (It's not really native theming - the gradient is drawn with Core Graphics gradients directly into the CGContext, and for the rest I use platform colors.)

Chris - those sceenshots seem to indicate that you're doing something nonstandard with your toolbar. Can you elaborate on it and reproduce the issue without it?

As I stated in the other bug, I am doing absolutely nothing to the toolbar. I can easily reproduce this issue with a fresh profile (and have, as I don't normally use Firefox, so I don't care about my profile data in it).

The screenshots on the other bug don't have the icons for the back/forward/reload/home buttons. Is this an option somewhere in the FF prefs? I'm pretty sure it doesn't ship that way out of the box.

(In reply to comment #24) > The screenshots on the other bug don't have the icons for the > back/forward/reload/home buttons. Is this an option somewhere in the FF prefs? That's probably the result of View -> Customise Toolbar -> "Text". Like I said, it doesn't make any difference whether I do this with a fresh profile or not; the chrome is being colour-managed incorrectly and inconsistently. If you want me to take new screenshots to prove it, fine. I'd rather we figure out what's going on here than continue wasting my time explaining that yes, I really can reproduce this bug.

(In reply to comment #25) > That's probably the result of View -> Customise Toolbar -> "Text". Got it - thanks. > Like I said, it doesn't make any difference whether I do this with a fresh > profile or not; the chrome is being colour-managed incorrectly and > inconsistently. If you want me to take new screenshots to prove it, fine. I'd > rather we figure out what's going on here than continue wasting my time > explaining that yes, I really can reproduce this bug. I don't doubt your ability to reproduce the bug. I looked at your screenshots, found something different than what shows up on my screen, and wanted to make sure that wasn't the issue. Can you attach your system profile to the bug? Also, what display are you using?

Here's the profile that's giving this result.

And here's another ColorSync profile, created brand-new tonight, that also exhibits the same problem.

Confirmed. I hauled mscott's PowerMac G5 out of dbaron's office and fired up a nightly. Sure enough, I got the orange bar at the top. It seems that it has to do with some endian-ness issues where we don't properly flip some bytes in the big-endian case in the mac widget code. A fix is forthcoming. Thanks for your help on this chris.

Fix added. Flagging vlad for review. I've put the patch up on the tryserver, so we should have ppc builds within the hour. I'll fire it up on the g5 when it's done to make sure.

tryserver builds fix the problem for me. For reference, they're at https://build.mozilla.org/tryserver-builds/2008-09-10_14:08-bobbyholley@stanford.edu-bholleypixwrapper/ Pushed in 4fab4fa3d85c, so it should show up in the nightlies. Resolving as fixed. Let me know if this doesn't fix it Chris.

Made a fresh Firefox 3.0.1 profile by running Firefox 3.0.1, set gfx.color_management.enabled to true, quit Firefox, re-launched, problem appears. Deleted profile. Made a fresh Minefield profile by running the tryserver build from comment 31, set gfx.color_management.mode to 1, quit Minefield, re-launched, no problems. Looks FIXED to me. Thanks, Bobby.

Marking verified based on comment 32.

Could this fix also come with a Firefox 3.0.x update?

Not a security fix. I doubt so.