New issue
Advanced search Search tips

Issue 752095 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Task

Blocking:
issue 752022
issue 850380



Sign in to add a comment

Calculate sticky position constraints during layout walk.

Project Member Reported by flackr@chromium.org, Aug 3 2017

Issue description

Currently we don't produce sticky position constraints until the compositing inputs update (pre-spv2) or prepaint walk (spv2). Asking for the offset before this stage has run just returns 0. Since sticky position locations are needed for layout queries ( issue 672457 ), scrolling ( issue 746590 ,  issue 740417 ) we added the ability to ensure compositing inputs were clean but it was not very clean.

Since the spec requires knowing the sticky offset to calculate overflow size (issue 752022) we should save the nearest ancestor overflow layer during the layout tree walk so that we can gather sticky elements within overflow scrollers during the layout walk and compute sticky position constraints as part of completing the layout for each overflow scroller.

Doing this should clean up code we added to support forcing compositing inputs clean, and should eliminate the long tail of bugs which may occur today from using an incorrect sticky position offset.
 
I took a brief look at this on Friday, and though I am still trying to grok layout, I think we want to (names made up and not final):

1. Add a 'nearest ancestor overflow' pointer to the LayoutState (https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/layout/LayoutState.h)

2. Update this pointer during the layout walk, though not sure when. LayoutBlock::PerformLayout(), if GetScrollableArea() is non-null ?

3. When we reach a sticky element, do LayoutState::NearestAncestorOverflow()->RegisterStickyElement(). Again not sure where, possibly need to add LayoutObject::PerformLayout() since sticky is valid for both LayoutBox and LayoutInline?

4. In PaintLayerScrollableArea::UpdateAfterLayout, iterate over our registered sticky elements and compute constraint information.

Does this sound valid? We may also need to make sure that the sticky elements set themselves as needing layout properly when sticky changes, including needing their ancestor overflow element to run layout?
Cc: -smcgruer@chromium.org flackr@chromium.org
Owner: smcgruer@chromium.org
Cc: smcgruer@chromium.org
Owner: ----
Status: Available (was: Assigned)
No further work is currently happening on sticky; moving to Available.
Blocking: 850380

Sign in to add a comment