Unable to reproduce the issue on reported version 61.0.3163.100 and latest canary 63.0.3236.0 using Mac 10.12.6 with the attached file(sample_DOM_color.html).

Attaching screencast for your perusal.
Could you please share the sample test file for further triaging the issue from TE End

Thanks for filing the issue...!!

Deleted: sample_DOM_color.html 786 bytes

sample_DOM_color.html 786 bytes View Download

Deleted: Oct-11-2017-10-40-AM.mp4 478 KB

	Oct-11-2017-10-40-AM.mp4 478 KB View Download

I uploaded an example to demonstrate this issue, with two screenshots so that you can see the issue.

First screenshot shows the second last node "2007 Q2" shows green but its background color is red. 2nd screenshot shows all nodes renders in correct colors if hardware acceleration is disabled.

Deleted: color issue on mac chrome.zip 235 KB

color issue on mac chrome.zip 235 KB Download

Deleted: '2007 Q2' shows as green but its background color is red.jpg 587 KB

	'2007 Q2' shows as green but its background color is red.jpg 587 KB View Download

Deleted: all colors rendering correct if hardware acceleration is disabled.jpg 76.0 KB

	all colors rendering correct if hardware acceleration is disabled.jpg 76.0 KB View Download

Thank you for providing more feedback. Adding requester "divya.padigela@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Tested the issue in MacBook Pro (Retina, 15-inch, Mid 2014), 10.12.6 using chrome reported version #61.0.3163.100 and latest canary #64.0.3241.0.

Following are the steps followed to reproduce the issue.
------------
1. Launched chrome browser.
2. Opened 222.html from color issue on mac chrome folder and observed that the second last node "2007 Q2" is in red colour in both chrome reported version #61.0.3163.100 and latest canary #64.0.3241.0. The behaviour is quite different from the attached screen shot i.e '2007 Q2' shows as green but its background color is red.

Attaching screen shots for reference.

Reporter@ - Could you please verify the attached screen shots and please let us know the expected and actual behaviour.

Thanks...!!

Deleted: 773465@M61.png 344 KB

	773465@M61.png 344 KB View Download

Deleted: 773465@M63.png 351 KB

	773465@M63.png 351 KB View Download

Hi,

Actually you reproduced this issue :) !!!

See the screenshot you posted for Chrome 61.0.3163.100, even the second last node "2007 Q2" is red, but others nodes show wrong color, for example, the last node is in red, but it is expected to be blue, please check your other screenshot for Chrome 64 as the baseline which has the expected behavior. I used the second last node as an example, because sometimes the node having the wrong color can keep changing.

Your screenshot for Chrome 64.0.3241.0 is expected behavior, if you compare your two screenshots, you will find they are different. One question, when the version of 64.0.3241 can be released as it seems to have expect result.

Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to reproduce the issue on mac os 10.12.6 Retina and the behavior is different in windows 10,ubuntu 14.04 and mac os 10.12.6 Non-Retinaa using chrome M61 #61.0.3163.100 & latest beta M62 #62.0.3202.52  channels.

This got fxed in latest dev and canary.

Hence providing reverse bisect using per revision bisect script,

Good Build : 63.0.3235.0 (Revision : 507234)
Bad Build : 63.0.3233.0 (Revision : 506599)

You are probably looking for a change made after 506893 (known good), but no later than 506894 (first known bad).

CHANGELOG URL:

The script might not always return single CL as suspect as some perf builds might get missing due to failure.

  https://chromium.googlesource.com/chromium/src/+log/6003385719f84349cac49dac3b87074e7e986047..ccc08f3c7721b28ff8e627fa742fddf8eb03f30f

 From the above CL , unable to find the actual suspect ,

@Could someone help us in assigning it to the concern owner.

Thanks!

Forwarding to Skia team, as the bisect above only contains skia roll.

Bad bisect?  +brian, mike to double check the skia changes

Looks like deferred proxies?

It looks like it is deferred proxies.

I've bisected it (on a MacBook Pro with an Intel HD Graphics 4000) to the Skia roll with:

https://skia-review.googlesource.com/c/skia/+/57282 (Disable deferred proxies a different way in Chrome)

For the interested, the fix for this bug appears in the 63.0.3237.0 (and above) canaries and has been cherry-picked back to M62.

I can't really explain the bisect results in #8.

On Win10 this bisects to the Skia roll that includes:

https://skia-review.googlesource.com/55381 (Always use draws instead of clears for ANGLE D3D11)

So this matches the bisect in #8 (except on Windows and not Mac) and seems to implicate the clearing bug.

I have verified that this bug is still fixed (on a MacBook Pro with an Intel HD Graphics 4000) in the 64.0.3255.0 Canary even though the causal feature was re-enabled in: https://chromium-review.googlesource.com/c/chromium/src/+/744683 (Reenable Skia's deferred proxies)