(Sorry, accidentally pressed return in the wrong place)

...I reported this earlier in  Issue 648364  but couldn't reproduce that reliably. This incorrect rendering does reproduce pretty reliably and it looks very bad -- it would be  poor to ship Chrome to Stable with this rendering bug present.

I didn't reproduce the exact same issue, but also reproduced corrupted rendering of the send bar that sometimes it doesn't keep at the bottom on scroll, sometimes it jumps on scroll or it's painted on the middle of the compose editor.

Bisected this to https://chromium.googlesource.com/chromium/src/+log/f5d32c3097963b67fc797d602b34a0380f508f0f..a9b2754f28b5f29378a348f05ba27abbb1853f03.

https://chromium.googlesource.com/chromium/src/+/87b0099aa31169f8c7a40b4f93b4a1e86ddf53a1 seems the culprit.

Is this specific to any OS or all OSs?

I reproduced on Mac Retina, but not on Linux (even with --enable-prefer-compositing-to-lcd-text).

What I reproduced is as below:
- Click the reply or reply all icon in gmail;
- Press Enter many times to make the new email very long;
- Use touchpad/mouse wheel to scroll the page, and observe the Send bar.

Expected: Scroll is smooth. The Send bar should stay at the bottom of the screen except when the page is near the bottom.

Actual: The Send bar sometimes jumps during scroll; sometimes disappears; sometimes the email compositing box grows out of the bottom of the screen and the Send bar is drawn across the middle of the compositing box.

Screen shots

Deleted: Screen Shot 2016-09-27 at 10.03.47 AM.png 234 KB

	Screen Shot 2016-09-27 at 10.03.47 AM.png 234 KB View Download

Deleted: Screen Shot 2016-09-27 at 10.03.58 AM.png 226 KB

	Screen Shot 2016-09-27 at 10.03.58 AM.png 226 KB View Download

My change is plausible because it changed the logic for some clipping behavior for enable-prefer-compositing-to-lcd-text. Odd it's Mac only though, and does not manifest on linux with the appropriate flags.

Could test try to reproduce this on a Pixel Chromebook with a Canary version? I believe that platform also uses the prefer-compositing-to-lcd-text flag by default.

ChromeOS dev channel should also have this change in it.

I cannot reproduce this with 55.0.2873.4. What I do see is the Send bar jumping around as if the position is being explicitly set in JS based on the scroll position. But it does stay where one would expect.

It's possible that the issues seen in comments 6 and 7 are due to Gmail bugs that have been fixed, although that doesn't gel with the bisect range. It's also plausible that turning on composite-opaque-scrollers for production builds has had some effect on this bug.

wangxianzhu@, kbr@, can either of you still repro?

I couldn't reproduce the corrupted rendering. However, the jumping behavior is still interesting. Before the range in #4, the Send bar doesn't jump around on scroll when it stay at the bottom (when it has position:fixed).

P.S. I just reproduced the issue with paint flashing enabled in devtools.

I just managed to repro. It relies on compositing the background with the foreground, as far as I can tell, because it only appears on prefer-compositing-to-lcd-text and seems to only happen when the background is such that we enable that mode. So it depends on the Gmail theme (default theme has the problem). I can make it happen on Win Canary which has composite-opaque-scroller provided I modify the CSS a little to set background-clip: padding-box on the scroller (which is a condition for getting the performance improvement).

flackr@, I thought we no longer needed background-clip: padding-box to get the background-paints-in-foreground behavior?

The only part of https://codereview.chromium.org/2259493004 that affected things not behind the flag was the change to CompositingReasonFinder related to CompositingReasonOutOfFlowClipping. I'll revert that and see what happens.

Re-enabling the logic for CompositingReasonOutOfFlowClipping fixes the problem of not drawing in the right place, but the Send bar still jumps around. With composited scrolling it's off by a frame on it's script updated position, presumably because the scroll handler is being called async, or something like that. I'm no expert.

I'm going to look into it on Mac before I commit the fix. Presumably it didn't jump around before so maybe there's some problem with the opaque scroller compositing that does not manifest with prefer-compositing-to-lcd-text.

Re 13: Correct, the default background clip, border-box, should paint into the background into the scrolling contents provided all of the other conditions are met. See https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/layout/LayoutBoxModelObject.cpp?q=LayoutBoxModelObject::hasLocalEquivalentBackground&sq=package:chromium&dr=CSs&l=167

I can no longer reproduce this on Mac Canary. Could someone else please try to verify that this particular issue is fixed?

That still leaves open the non-trivial chance that it's broken for other content, despite our inability to produce a failing test case.

I also can't reproduce any more on the current Mac Canary: 55.0.2879.0 (Official Build) canary (64-bit). Looks like the rendering is back to normal.

I still reproduced on 55.0.2879.0.
1. The Send bar jumps during scroll;
2. With Paint flashing enabled in DevTools, the Send bar doesn't render correctly (like the screen shots in #7). When the Send bar is position:fixed, it doesn't repaint but scrolls along with other contents.

I only see problems with 55.0.2879.0 when paint flashing. So I suppose we still revert the change.

Just reproduced without DevTools, and with DevTools opened but without paint flashing. Screen recording attached.

Deleted: gmail.mov 2.7 MB

gmail.mov 2.7 MB Download

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

commit 2d9b508d37b0fac7f0b3c4fcce5f8a278d4fb9d7
Author: schenney <schenney@chromium.org>
Date: Thu Oct 06 18:52:19 2016

Revert the removal of CompositingReasonOutOfFlowClipping

Change https://codereview.chromium.org/2382563002/ modified
the logic for compositing layers with a clip parent when
we prefer compositing to LCD text. Revert that change to fix
painting of fixed position clipped elements over accelerated
scrolling elements.

R=flackr@chromium.org
BUG= 650446 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

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

[modify] https://crrev.com/2d9b508d37b0fac7f0b3c4fcce5f8a278d4fb9d7/third_party/WebKit/LayoutTests/compositing/overflow/scroll-parent-absolute-with-backdrop-filter-expected.txt
[modify] https://crrev.com/2d9b508d37b0fac7f0b3c4fcce5f8a278d4fb9d7/third_party/WebKit/LayoutTests/virtual/prefer_compositing_to_lcd_text/compositing/overflow/scroll-parent-absolute-with-backdrop-filter-expected.txt
[modify] https://crrev.com/2d9b508d37b0fac7f0b3c4fcce5f8a278d4fb9d7/third_party/WebKit/Source/core/layout/compositing/CompositingReasonFinder.cpp
[modify] https://crrev.com/2d9b508d37b0fac7f0b3c4fcce5f8a278d4fb9d7/third_party/WebKit/Source/core/layout/compositing/CompositingRequirementsUpdater.cpp

Verified the revert on the latest M-55(55.0.2883.6) on MacBook Pro retina OS 10.11.6. This is working as intended and no rendering issue is seen as per the steps mentioned in C#0.

Note: I was able to reproduce the issue on the reported version:55.0.2872.0 on the same Mac laptop.

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

commit 2d9b508d37b0fac7f0b3c4fcce5f8a278d4fb9d7
Author: schenney <schenney@chromium.org>
Date: Thu Oct 06 18:52:19 2016

Revert the removal of CompositingReasonOutOfFlowClipping

Change https://codereview.chromium.org/2382563002/ modified
the logic for compositing layers with a clip parent when
we prefer compositing to LCD text. Revert that change to fix
painting of fixed position clipped elements over accelerated
scrolling elements.

R=flackr@chromium.org
BUG= 650446 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

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

[modify] https://crrev.com/2d9b508d37b0fac7f0b3c4fcce5f8a278d4fb9d7/third_party/WebKit/LayoutTests/compositing/overflow/scroll-parent-absolute-with-backdrop-filter-expected.txt
[modify] https://crrev.com/2d9b508d37b0fac7f0b3c4fcce5f8a278d4fb9d7/third_party/WebKit/LayoutTests/virtual/prefer_compositing_to_lcd_text/compositing/overflow/scroll-parent-absolute-with-backdrop-filter-expected.txt
[modify] https://crrev.com/2d9b508d37b0fac7f0b3c4fcce5f8a278d4fb9d7/third_party/WebKit/Source/core/layout/compositing/CompositingReasonFinder.cpp
[modify] https://crrev.com/2d9b508d37b0fac7f0b3c4fcce5f8a278d4fb9d7/third_party/WebKit/Source/core/layout/compositing/CompositingRequirementsUpdater.cpp

[Automated comment] removing mislabelled merge-merged-2840