New issue
Advanced search Search tips

Issue 808479 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Closed: Feb 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 1
Type: Bug

Blocking:
issue 417782



Sign in to add a comment

[root layer scrolls] paint bug with sticky objects

Project Member Reported by bokan@chromium.org, Feb 2 2018

Issue description

Chrome Version       : 66.0.3336.4
OS Version: Android
URLs (if applicable) : Any google search result page (e.g. search 'food' in omnibox)

What steps will reproduce the problem?
1. Run chrome with --root-layer-scrolls
2. Search for any term in omnibo
3. Scroll down

What happens instead of that?
A white rect is seen over- and under-laying the content. You may have to scroll up and down a few times to see it - scrolling slowly seems to make it happen more consistently. 

Could not reproduce without --root-layer-scrolls

 

Comment 1 by bokan@chromium.org, Feb 2 2018

Blocking: 417782

Comment 2 by bokan@chromium.org, Feb 2 2018

Summary: [root layer scrolls] Paint bug on Google SRP (was: [root layer scrolls] Paint bug on GSP)

Comment 3 by bokan@chromium.org, Feb 5 2018

Summary: [root layer scrolls] Paint bug (was: [root layer scrolls] Paint bug on Google SRP)
Looks like I forgot to attach the video
paintbug.mp4
13.0 MB View Download

Comment 4 by bokan@chromium.org, Feb 5 2018

I've since seen this on other pages and on desktop too. Where I've looked, there's always a sticky position element around.
Screenshot from 2018-02-05 10-55-15.png
199 KB View Download
Issue 808938 has been merged into this issue.
Cc: -skobes@chromium.org bokan@chromium.org
Owner: skobes@chromium.org
Status: Started (was: Available)
With dchecks on I get the following when scrolling past the sidebar sticking point of any Monorail page:

[78337:775:0206/101550.034163:FATAL:LayoutGeometryMap.cpp(186)] Check failed: RoundedIntRect(layout_object_mapped_result) == RoundedIntRect(result.BoundingBox()) || layout_object_mapped_result.MayNotHaveExactIntRectRepresentation() || result.BoundingBox().MayNotHaveExactIntRectRepresentation(). Rounded: "4,0 237x446" vs "4,-3 237x446". Original: "4,0 237x446.453" vs "4,-3 237x446.453"
0   Chromium Framework                  0x000000010d1560ec base::debug::StackTrace::StackTrace(unsigned long) + 28
1   Chromium Framework                  0x000000010d17b8e0 logging::LogMessage::~LogMessage() + 224
2   Chromium Framework                  0x0000000111e514aa blink::LayoutGeometryMap::MapToAncestor(blink::FloatRect const&, blink::LayoutBoxModelObject const*) const + 874
3   Chromium Framework                  0x00000001121beb95 blink::CompositingInputsUpdater::UpdateRecursive(blink::PaintLayer*, blink::CompositingInputsUpdater::UpdateType, blink::CompositingInputsUpdater::AncestorInfo) + 709
4   Chromium Framework                  0x00000001121bf5d2 blink::CompositingInputsUpdater::UpdateRecursive(blink::PaintLayer*, blink::CompositingInputsUpdater::UpdateType, blink::CompositingInputsUpdater::AncestorInfo) + 3330
5   Chromium Framework                  0x00000001121bf5d2 blink::CompositingInputsUpdater::UpdateRecursive(blink::PaintLayer*, blink::CompositingInputsUpdater::UpdateType, blink::CompositingInputsUpdater::AncestorInfo) + 3330
6   Chromium Framework                  0x00000001121be804 blink::CompositingInputsUpdater::Update() + 116
7   Chromium Framework                  0x00000001121c903c blink::PaintLayerCompositor::UpdateIfNeeded(blink::DocumentLifecycle::LifecycleState, blink::CompositingReasonsStats&) + 332
8   Chromium Framework                  0x00000001121c8a7b blink::PaintLayerCompositor::UpdateIfNeededRecursiveInternal(blink::DocumentLifecycle::LifecycleState, blink::CompositingReasonsStats&) + 683
9   Chromium Framework                  0x00000001121c8526 blink::PaintLayerCompositor::UpdateIfNeededRecursive(blink::DocumentLifecycle::LifecycleState) + 182
10  Chromium Framework                  0x000000011197945e blink::LocalFrameView::UpdateLifecyclePhasesInternal(blink::DocumentLifecycle::LifecycleState) + 814
11  Chromium Framework                  0x000000011197911a blink::LocalFrameView::UpdateAllLifecyclePhases() + 122
12  Chromium Framework                  0x00000001120c3ece blink::PageAnimator::UpdateAllLifecyclePhases(blink::LocalFrame&) + 30
13  Chromium Framework                  0x00000001118d3258 blink::WebViewImpl::UpdateLifecycle(blink::WebWidget::LifecycleUpdate) + 152
14  Chromium Framework                  0x00000001119f99db blink::WebViewFrameWidget::UpdateLifecycle(blink::WebWidget::LifecycleUpdate) + 107

... which is the same crash affecting fast/scroll-behavior/scroll-into-view-sticky.html ( issue 807162 )
Cc: -szager@chromium.org flackr@chromium.org smcgruer@chromium.org
Owner: szager@chromium.org
szager is looking at this, also cc'ing flackr and smcgruer in case they have ideas
Summary: [root layer scrolls] paint bug with sticky objects (was: [root layer scrolls] Paint bug)
Cc: szager@chromium.org vmp...@chromium.org
 Issue 807162  has been merged into this issue.
It looks like the layer position hasn't been updated with the sticky offset after the scroll in your failure case. This should be easy to verify by adding an unconditional call to UpdateLayerPosition right before calling geometry_map_.PushMappingsToAncestor in CompositingInputsUpdater::UpdateRecursive and seeing if the issue goes away.

If so, I suspect that the scrolling path needs to call UpdateLayerPositionsAfterOverflowScroll - which used to be called from LocalFrameView::UpdateLayersAndCompositingAfterScrollIfNeeded if I remember correctly.
(Note that RLS also changes the coordinate space for layer positions.)
flackr@ is correct in comment #12: the bug is out-of-date layer position after overflow scroll.

We recently made a change to skip running UpdateLayerPositionsAfterOverflowScroll for the root layer to fix a performance regression for root layer scrolling compared to non-RLS.  But that is a problem for sticky objects that stick to the root scroller.

The fix will likely be to use LocalFrameView::viewport_constrained_objects_ to update layer position for these objects on a root layer scroll.
Project Member

Comment 15 by bugdroid1@chromium.org, Feb 8 2018

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

commit ef082b8cab887301fbba11ba146a155a3057fdf6
Author: Stefan Zager <szager@chromium.org>
Date: Thu Feb 08 00:41:21 2018

[RootLayerScrolls] Fix position:sticky layer position after scroll

As a performance optimization, when the root layer scrolls we don't
call UpdateLayerPositionsRecursive (which is expensive).  For most
layers whose position depends on the scroll offset of the root layer
that's fine; PaintLayer::Location() factors in the scroll offset of
the root layer.  However, layers associated with sticky objects have a
more complex relationship with the scroll offset of their scrolling
ancestor (see LayoutBoxModelObject::StickyPositionOffset()).  So it
makes sense to update their layer position from
UpdateLayerPositionsAfterOverflowScroll.

BUG= 808479 
R=flackr@chromium.org,skobes@chromium.org

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I74e023b6c8390093fc493a7f0efec9c8f5601034
Reviewed-on: https://chromium-review.googlesource.com/907692
Reviewed-by: Steve Kobes <skobes@chromium.org>
Commit-Queue: Stefan Zager <szager@chromium.org>
Cr-Commit-Position: refs/heads/master@{#535219}
[modify] https://crrev.com/ef082b8cab887301fbba11ba146a155a3057fdf6/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/ef082b8cab887301fbba11ba146a155a3057fdf6/third_party/WebKit/Source/core/paint/PaintLayer.cpp
[modify] https://crrev.com/ef082b8cab887301fbba11ba146a155a3057fdf6/third_party/WebKit/Source/core/paint/PaintLayerScrollableArea.cpp
[modify] https://crrev.com/ef082b8cab887301fbba11ba146a155a3057fdf6/third_party/WebKit/Source/core/paint/PaintLayerScrollableArea.h

Status: Fixed (was: Started)

Sign in to add a comment