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

[bugzilla-daemon at webkit.org]

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

--- Comment #5 from Simon Fraser (smfr) <simon.fraser at apple.com> ---
Comment on attachment 373491
  --> https://bugs.webkit.org/attachment.cgi?id=373491
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=373491&action=review

Isn't it a bit late to be making refactoring changes like this?

> Source/WebCore/page/scrolling/cocoa/ScrollingTreePositionedNode.mm:74
> +        if (!children() || children()->size() != 1)
> +            return true;

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?

> Source/WebCore/page/scrolling/cocoa/ScrollingTreePositionedNode.mm:76
> +        // In there is a child node for the same layer then this node exits for scroll propagationg

"If there". propagationg -> propagation?

> 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.

-- 
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/f552211f/attachment-0001.html>