It's probably because the CL is wrong for non-RLS mode.

Might be the same issue as  bug 825280 ?

any updates on this issue yet? It's marked as RB-Beta and we have an M66 Beta release on Wednesday. 

I can repro this locally on 66.0.3359.45 on a Macbook, but only with --force-device-scale-factor=1.0

However the bisect result wasn't accurate. I reverted my patch in M66 locally, but the bug still repro. It is probably something else.

I could repro on 66.0.3359.43 too. I think the repro is not very reliable, as I can see the menu contents flash in/out while scrolling. The bisect needs to be redone.

This can be repro'd on r543584 too. I don't think it is fixed by
 https://chromium-review.googlesource.com/c/chromium/src/+/961643

I can't repro this on ToT today (r545883). I'll try to further bisect this.

I bisected again, and it seems r543584 did fix the issue on trunk.

Now it is puzzling why the same CL is not effective in M66... Could it be sensitive to SPv175?

Able to reproduce the issue on reported chrome version 66.0.3359.45 using Windows-10, Mac 10.12.6 & Ubuntu 14.04
Re-bisected the issue again, as the issue is not seen on latest chrome version# 67.0.3379.0, hence providing the reverse bisect info as per comment#0

Last bad build: 67.0.3371.0
First good build: 67.0.3372.0

Change Log: https://chromium.googlesource.com/chromium/src/+log/67.0.3371.0..67.0.3372.0?pretty=fuller&n=10000
Commit: https://chromium.googlesource.com/chromium/src/+/d09d2073659030ed2d5ea3f3b8331583d46796c0
Reviewed-on: https://chromium-review.googlesource.com/961643

Observed the issue on chrome version# 66.0.3359.45, observed the break in branch builds, hence providing the manual change log from omahaproxy

Last good build: 66.0.3359.44
First bad build: 66.0.3359.45

Change Log: https://chromium.googlesource.com/chromium/src/+log/66.0.3359.44..66.0.3359.45?pretty=fuller&n=10000
Commit: https://chromium.googlesource.com/chromium/src/+/cee8973f56386ace74fa77b87e81224c04ca7b26
Reviewed-on: https://chromium-review.googlesource.com/971866

Re-adding Beta blocker as this is recent break in M-66, feel free to adjust the same if not applicable.

Thanks!

Since this isn't highly reproducible (I just tried it on Mac and couldn't), and this is already present in last M66 Beta, we will not block tomorrow's beta on this. The fix should still be targeted asap. 

Here's a minimal repro.

Deleted: test11.html 721 bytes

test11.html 721 bytes View Download

I added some debug output locally. It seems that the fixed-pos compensation is already somehow applied in M66 prior to the patch (which is surprising because the source code is identical in M66 and trunk), and with my patch the compensation will be doubly applied. I think it is safe to just revert the merge.

I created a revert here: https://chromium-review.googlesource.com/c/chromium/src/+/985254
but I don't have the permission to submit it. abdulsyed@ could you help?

Also I still worry that even prior to my merge, the logout menu can be seen flashing white while scrolling. I suggest that we revert my merge, close this bug, then open another bug to continue investigation.

Are you landing the revert in branch directly? Can you please add Merge-Request-66 label when ready to merge? 

Yes I'm reverting in a branch directly.

To clarify, it is reverting a CL that is cherry picked into M66. While the CL worked as intended in trunk, somehow it resulted in a bad interaction in M66, thus we only want to cancel the merge to M66 but not reverting it in trunk.

This bug requires manual review: M66 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), josafat@(ChromeOS), abdulsyed@(Desktop)

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

Actually, never mind. I think I found the root cause why the bug only shows up in M66.

I turns out that as a side effect, one of my optimization patch in trunk: https://chromium-review.googlesource.com/c/chromium/src/+/952540 fixed a bug whether LayoutView should be considered a scrolling container of fixed-pos elements with RLS. 

While that CL is too complex to bring to M66, I think a one line patch can be done to achieve the same effect. I'll be tailoring the patch for M66 right now.

trchen@, Gentle ping! Do we have any further update on this?

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

commit 34569e4441bf99e40a6ede00237e03f064d3bd93
Author: Tien-Ren Chen <trchen@chromium.org>
Date: Wed Apr 04 04:29:12 2018

[Blink] Correct ignore root layer scrolling in PaintLayerClipper

The flag kIgnoreOverflowClipAndScroll can be passed to PaintLayerClipper
to compute clip rect in the space of the scrolled box of the root layer.
This is done by first computing clip rect in the space of the border box,
then apply an anti-scroll to the rect if the rect was affected by the
scroll.

Prior to this CL, the condition that determines whether the anti-scroll
is needed was incorrect. It used a function that determines whether two
layers can ever have relative movement upon scrolled, and is allowed to
return false positive. This CL instead traverses the layer tree to see
whether the root layer is a part of the containing block chain.

BUG= 825543 

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: Ifec0bddb9511aa3b878cc0757bb8fb6f59cfb0ab
Reviewed-on: https://chromium-review.googlesource.com/987319
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Commit-Queue: Tien-Ren Chen <trchen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#547979}
[modify] https://crrev.com/34569e4441bf99e40a6ede00237e03f064d3bd93/third_party/WebKit/Source/core/paint/PaintLayer.cpp
[modify] https://crrev.com/34569e4441bf99e40a6ede00237e03f064d3bd93/third_party/WebKit/Source/core/paint/PaintLayer.h
[modify] https://crrev.com/34569e4441bf99e40a6ede00237e03f064d3bd93/third_party/WebKit/Source/core/paint/PaintLayerClipper.cpp
[modify] https://crrev.com/34569e4441bf99e40a6ede00237e03f064d3bd93/third_party/WebKit/Source/core/paint/PaintLayerClipperTest.cpp

Cherrypicked r547979 locally to verify it fixed this bug on M66. Let's bake one or two day then we can merge it to M66.

This bug requires manual review: We are only 12 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), josafat@(ChromeOS), abdulsyed@(Desktop)

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

How does the change look in canary today?

Please verify if this has been fixed in canary.

M67 was never affected by this bug. We are baking to make sure the CL has no adverse effects. So far I haven't seen any related regression, so I think it could be considered safe to merge.

Ok cool - approving merge to M66. Branch:3359. Let's monitor it closely post Beta release on Wednesday.

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

commit 626754cb88b616fdab3db3222deb008fc34763ec
Author: Tien-Ren Chen <trchen@chromium.org>
Date: Mon Apr 09 20:36:22 2018

[Blink] Correct ignore root layer scrolling in PaintLayerClipper

The flag kIgnoreOverflowClipAndScroll can be passed to PaintLayerClipper
to compute clip rect in the space of the scrolled box of the root layer.
This is done by first computing clip rect in the space of the border box,
then apply an anti-scroll to the rect if the rect was affected by the
scroll.

Prior to this CL, the condition that determines whether the anti-scroll
is needed was incorrect. It used a function that determines whether two
layers can ever have relative movement upon scrolled, and is allowed to
return false positive. This CL instead traverses the layer tree to see
whether the root layer is a part of the containing block chain.

BUG= 825543 

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: Ifec0bddb9511aa3b878cc0757bb8fb6f59cfb0ab
Reviewed-on: https://chromium-review.googlesource.com/987319
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Commit-Queue: Tien-Ren Chen <trchen@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#547979}(cherry picked from commit 34569e4441bf99e40a6ede00237e03f064d3bd93)
Reviewed-on: https://chromium-review.googlesource.com/1003151
Reviewed-by: Tien-Ren Chen <trchen@chromium.org>
Cr-Commit-Position: refs/branch-heads/3359@{#629}
Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276}
[modify] https://crrev.com/626754cb88b616fdab3db3222deb008fc34763ec/third_party/WebKit/Source/core/paint/PaintLayer.cpp
[modify] https://crrev.com/626754cb88b616fdab3db3222deb008fc34763ec/third_party/WebKit/Source/core/paint/PaintLayer.h
[modify] https://crrev.com/626754cb88b616fdab3db3222deb008fc34763ec/third_party/WebKit/Source/core/paint/PaintLayerClipper.cpp
[modify] https://crrev.com/626754cb88b616fdab3db3222deb008fc34763ec/third_party/WebKit/Source/core/paint/PaintLayerClipperTest.cpp

Verified the fix on the latest M-66(66.0.3359.106) on Mac OS 10.13.3 as per the test steps in C#0. This seems to be working fine now.