Able to reproduce the issue on amc 10.11.6 chrome version 54.0.2840.98

But this is working fine on latest dev 56.0.2914.3 and canary 56.0.2923.0 - Please find the screenshot

seems the issue got fixed in later versions. Could you please recheck the same on latest versions and update the thread

Deleted: Screen Shot 2016-11-17 at 7.05.54 PM.png 259 KB

	Screen Shot 2016-11-17 at 7.05.54 PM.png 259 KB View Download

I confirm it works correctly in Chrome Canary.

Tried reverse bisect using per-revision bisect script,

Good Build : 55.0.2847.0 (Revision : 416149)
Bad Build : 55.0.2846.0 (Revision : 415833)

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

CHANGELOG URL:

  https://chromium.googlesource.com/chromium/src/+log/f3d89bb80e61354b320e7ffaa834dc1fac7cd6f2..1e7e98e048508e3c158244c409830f5a4ebc0630

Unable to find the suspect from the above CL , could anyone please help us in assigning it to the right owner.

Thanks!

Not JavaScript/V8 related.

From the above CL provided in Comment # 4, suspecting the below.
Review-Url: https://codereview.chromium.org/2297603002 
Another possible suspect :
Review-Url: https://codereview.chromium.org/2303743002
qiankun.miao@/senorblanco@ : Could you please take a look into this if its related to your change, else help us assigning to an appropriate owner for the same.

And added ReleaseBlock-Stable against M55, please undo if not appropriate.

My change enabled functionality in Skia, but it is still hidden behind a compile-time flag in Chrome, so it could not cause this.

Perhaps https://chromium.googlesource.com/chromium/src/+/0230527ec6f04133dcbeb488474c13e895157ea5 may also have fixed it?

Reverting Eric's https://chromium.googlesource.com/chromium/src/+/0230527ec6f04133dcbeb488474c13e895157ea5 and Qiankun's https://codereview.chromium.org/2297603002 did not cause the bug to come back.

Doing my own bisect points at having been fixed by flackr's https://chromium.googlesource.com/chromium/src/+/77e72c03da749413cecee992ba27636fdd6bbfe1. It doesn't revert cleanly, though (to see if reverting it would bring the bug back). And it seems like perhaps it's just hiding the problem. But I'm kind of out of my depth here.

(Note also: the bug repros in Safari 10.0.1 in hidpi, so it looks like something we inherited from WebKit.)

unassigning me. This is a bug existed for very long time. I reproduced it with Revision: 349080 on mid-2015 Mac Pro, 10.12.2. What I see is it was fixed by https://codereview.chromium.org/2302743004 which relanded https://codereview.chromium.org/2264663002/.

A friendly reminder that M55 Stable is launch is coming soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch latest by November 28th, 4:00 PM PT in order to make into the desktop Stable final build cut (sooner the better). Thank you!

+chrishtr, PTAL comment #12. Thank you.

Rob could you take a look?

Looks like the graphics layer on the scroller is rounding up and the scrolling contents layer is rounding down. It would make sense that my patch which paints the background into the scrolling contents layer would fix this particular case but it wouldn't fix the general case where the scroller background was not local equivalent (e.g. http://output.jsbin.com/dugimupora). However, even this case seems to be fixed on canary, I think by https://chromium.googlesource.com/chromium/src/+/6c715c7a413e006594b26a2b59783d2d9d01f311 which correctly sizes the scrolling content).

It seems to me though that this has always been a problem (See comment #12) so we don't need any action here, right?

Agreed.