Using the per-revision bisect providing the bisect results,
Good build:57.0.2950.0 (Revision : 438011)
Bad build:57.0.2951.0 (Revision : 438385)

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

CHANGELOG URL:

The script might not always return single CL as suspectas some perf builds might get missing due to failure.
 
https://chromium.googlesource.com/chromium/src/+log/6140d6c6a50690dbc0c7d30e753104883a9873a0..c765a85995920f79d3132e06a2c146316b823c3f

From the CL above, assigning the issue to the concern owner 

@smcgruer - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Review-Url: https://codereview.chromium.org/2561183002

Thanks!

This is likely caused by my change, as it changes where the background contents are painted. There is likely some underlying bug when painting into the composited scrolling layer.

Unfortunately I am unable to reproduce on my home Windows desktop on 57.0.2952.1 , with the screen resolution set to 1280x1024. I will attempt to locate a Windows machine in the office and try again today.

Seems like this might have the same underlying cause as  issue 664904 .

I can't repro on either Win 10 or Win 7 with 57.0.2952.0. That's at 2560x1600.

But I can repro at 1280x1024 and in fact if you set the browser window size to 1282 (and probably 1280) it also reproduces. It may reproduce on other platforms at that size too.

Neither of the other "Unwanted black line" bugs reproduce at that resolution.

Yes, I managed to reproduce a similar or identical issue on Linux 57.0.2953.0 (Developer Build) (64-bit), by launching with:

./out/Default/chrome --window-size="1282x1024" https://support.google.com/chrome/?p=help&ctx=menu#topic=3227046


See attached image.

I will now check that reverting the revert fixes this issue, so that we have a known path out of the regression :).

Deleted: Screenshot from 2016-12-15 09:34:56.png 103 KB

	Screenshot from 2016-12-15 09:34:56.png 103 KB View Download

Confirmed that reverting c765a85995920f79d3132e06a2c146316b823c3f gets rid of the cyan line in my reproduction. I assume there is a painting bug when the background is being painted to the composited scrolling contents layer, unsure why it would be cyan though.

Given that we are fast approaching holiday season, I don't expect to have time to look at the underlying cause. Unless anyone else wants to take this over (speak up soon :)), later today I will revert c765a85995920f79d3132e06a2c146316b823c3f and re-open the original  http://crbug.com/646464  with additional details from this bug.

The cyan color is used in a debug build to indicate unpainted area of a layer that is supposed to be fully opaque.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4baddb7eb1745ba1f39697e89e303805f90efe16

commit 4baddb7eb1745ba1f39697e89e303805f90efe16
Author: smcgruer <smcgruer@chromium.org>
Date: Thu Dec 15 19:48:37 2016

Revert of Revert "Disable local background equivalence when we have a box shadow due to painting bug." (patchset #5 id:80001 of https://codereview.chromium.org/2561183002/ )

Reason for revert:
Caused a regression in drawing backgrounds when the window was sized around 1280x1024. Regression seen in at least Windows and Linux - see  http://crbug.com/674429 

BUG= 674429 

Original issue's description:
> Revert "Disable local background equivalence when we have a box shadow due to painting bug."
>
> This reverts commit a12e7a002f85301bf013b45e6e8bb61455304a76.
>
> BUG= 646464 
>
> TEST=Visit http://output.jsbin.com/vucefi, confirm that both boxes have
> box shadows and the first box has sub-pixel AA text
>
> Committed: https://crrev.com/c765a85995920f79d3132e06a2c146316b823c3f
> Cr-Commit-Position: refs/heads/master@{#438020}

TBR=wangxianzhu@chromium.org,chrishtr@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 646464 

Review-Url: https://codereview.chromium.org/2576423002
Cr-Commit-Position: refs/heads/master@{#438897}

[modify] https://crrev.com/4baddb7eb1745ba1f39697e89e303805f90efe16/third_party/WebKit/LayoutTests/compositing/overflow/scrollbar-layer-placement-expected.txt
[add] https://crrev.com/4baddb7eb1745ba1f39697e89e303805f90efe16/third_party/WebKit/LayoutTests/platform/android/compositing/overflow/scrollbar-layer-placement-expected.txt
[add] https://crrev.com/4baddb7eb1745ba1f39697e89e303805f90efe16/third_party/WebKit/LayoutTests/platform/mac-mac10.10/virtual/prefer_compositing_to_lcd_text/compositing/overflow/scrollbar-layer-placement-expected.txt
[add] https://crrev.com/4baddb7eb1745ba1f39697e89e303805f90efe16/third_party/WebKit/LayoutTests/platform/mac-retina/virtual/prefer_compositing_to_lcd_text/compositing/overflow/scrollbar-layer-placement-expected.txt
[add] https://crrev.com/4baddb7eb1745ba1f39697e89e303805f90efe16/third_party/WebKit/LayoutTests/platform/win/virtual/prefer_compositing_to_lcd_text/compositing/overflow/scrollbar-layer-placement-expected.txt
[modify] https://crrev.com/4baddb7eb1745ba1f39697e89e303805f90efe16/third_party/WebKit/Source/core/layout/LayoutBoxModelObject.cpp

Tested the issue on Latest Dev# 57.0.2970.0 on Windows and issue is no more reproducible.
Hence adding TE-Verified Labels.
Note: Adding Screenshot for further reference.
Thank You.

Forgot to attach screenshot.
Thank You.

Deleted: 674429.png 138 KB

	674429.png 138 KB View Download