[Webkit-unassigned] [Bug 199514] Clean up ScrollingTreeFixedNode::applyLayerPositions

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=199514

--- Comment #6 from Antti Koivisto <koivisto at iki.fi> ---

> I don't understand this test. Why does the number of children affect
> behavior; can't a positioned node have any number of descendant fixed or
> sticky or scrolling nodes?

This check...

> > Source/WebCore/page/scrolling/cocoa/ScrollingTreePositionedNode.mm:83
> > +        if (is<ScrollingTreeStickyNode>(child))
> > +            return downcast<ScrollingTreeStickyNode>(child).layer() != m_layer;
> > +        if (is<ScrollingTreeFixedNode>(child))
> > +            return downcast<ScrollingTreeFixedNode>(child).layer() != m_layer;
> 
> Whether it's the same layer seems like implementation detail. I might make
> more layers in RenderLayerBacking and break this.

...along with these matches the tower build in RenderLayerCompositor::updateScrollCoordinationForLayer where we can have multiple scrolling tree nodes for the same layer. In this case the PositionedNode doesn't do any positioning, the sticky/fixed child node does. However it is still needed so that the scroll updates propagate correctly and that we can establish scrolling relations in UI process.

This is obviously not a good way to do things. I think we should combine Fixed/Sticky/Absolute into a single class and never have more than one node per layer.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190705/a570cc93/attachment.html>