Bug 118576 - REGRESSION(r120021): Weird color differences on Acid3 test.
Summary: REGRESSION(r120021): Weird color differences on Acid3 test.
Status: RESOLVED WORKSFORME
Alias: None
Product: WebKit
Classification: Unclassified
Component: Images (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac (Intel) OS X 10.8
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-11 14:20 PDT by Zev Eisenberg
Modified: 2013-07-16 10:02 PDT (History)
5 users (show)

See Also:


Attachments
screen recording of the bug (3.56 MB, video/quicktime)
2013-07-11 14:20 PDT, Zev Eisenberg
no flags Details
test case (122 bytes, text/html)
2013-07-16 06:28 PDT, zalan
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Zev Eisenberg 2013-07-11 14:20:52 PDT
Created attachment 206488 [details]
screen recording of the bug

Steps to Reproduce:
1. Go to http://acid3.acidtests.org in Safari or Webkit Nightly. I was able to reproduce this in 6.0.5 (8536.30.1) and 6.0.5 (8536.30.1, 538+).
2. Command-click the Reference Rendering link to open it in a new tab.
3. Switch back and forth between the two tabs.

Expected Results:
The colors in the six colorful squares are identical between the real test and the reference rendering.

Actual Results:
The colors are different. To my eyes, the blue square is the most obviously a different color, but sampling the attached video with e.g. DigitalColor Meter.app on a Mac will reveal that they are all different colors.

Here's where it gets weird: if I refresh the reference rendering page, as shown in the attached video, the colors then match up perfectly between the reference rendering and the actual test.

Regression:
I believe this started within the last several months, certainly less than a year. I noticed it a while ago, but it didn't occur to me to report it until just now.

Notes:
This problem does not seem to exist in Firefox. The current stable build of Chrome fails miserably at the Acid3 test (no colored squares show up), so I was unable to determine whether it happens there. As far as I can tell from screenshots, the problem is not present in Mobile Safari on an iPad mini running iOS 6.1.3.
Comment 1 zalan 2013-07-16 06:28:43 PDT
Created attachment 206773 [details]
test case

To repo this bug, click on the link (with command button down) and manually switch over to the new tab. if the <a> has 'target=blank' so that the tab gets activated right after the navigation, the color diff does not occur.
Comment 2 Simon Fraser (smfr) 2013-07-16 08:25:41 PDT
Possibly fixed in Mavericks?
Comment 3 Zev Eisenberg 2013-07-16 09:55:54 PDT
(In reply to comment #2)
> Possibly fixed in Mavericks?

I can not reproduce this in Mavericks beta 3. Does this mean it should be closed? What was the problem, and how was it fixed?
Comment 4 zalan 2013-07-16 09:56:46 PDT
(In reply to comment #2)
> Possibly fixed in Mavericks?
Indeed. Can't repro on Mavericks.
Comment 5 Simon Fraser (smfr) 2013-07-16 10:02:43 PDT
QuartzCore uses two different code paths (one when offscreen) for CG rendering, and one of them has color matching bugs.