The test was added in http://trac.webkit.org/changeset/68323, and it's been getting image diffs since then. The animation is subtle enough (going from opacity .8 to .9) that I'm not sure if it's just a slight color difference in Chromium or an actual behavior difference.
Created attachment 69024 [details] Patch
Not 100% sure why the more subtle opacity change caused image diffs with the Chromium DRT (precision issues?), but since the intent of the test is to test two properties changing (not image fidelity), it still seems valid with this change.
Comment on attachment 69024 [details] Patch Nevermind about this patch, I wasn't actually passing --chromium to NRWT, which is why this test was passing with these baselines.
Actually, it seems to be the Mac port that has the precision issues. At the point where the pixel dump is done, the moving box has opacity of 0.5. I would expect the color on the screen to be (0*.5 + 255 * .5, 128 * .5 + 0 * 0.5, 0 * .5 + 0 * 0.5) = (128, 64, 0). However, the Mac port sees (125, 89, 7). Is this color correction in action?
Created attachment 69027 [details] Patch
Comment on attachment 69027 [details] Patch We prefer to keep green boxes indicating success. The almost-red box in the result here communicates failure. Maybe it would be better not to use a red background square, but to have a box which surrounds the success location.
Created attachment 69147 [details] Patch
Actually, I don't have to touch the Mac baselines at all if I make the opacity transition go from 0.7 to 1.0 (like the latest patch). Is that OK?
Comment on attachment 69147 [details] Patch Clearing flags on attachment: 69147 Committed r68619: <http://trac.webkit.org/changeset/68619>
All reviewed patches have been landed. Closing bug.