Bug 180002 - ScrollingStateNode::reconcileLayerPositionForViewportRect always starts from the root node
Summary: ScrollingStateNode::reconcileLayerPositionForViewportRect always starts from ...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Frames (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
Depends on:
Blocks: 149264 171667
  Show dependency treegraph
Reported: 2017-11-24 04:21 PST by Frédéric Wang (:fredw)
Modified: 2018-01-15 09:18 PST (History)
1 user (show)

See Also:

Patch (9.22 KB, patch)
2017-11-24 04:21 PST, Frédéric Wang (:fredw)
no flags Details | Formatted Diff | Diff
Patch (applies on top of bugs 173833 and 179946) (12.77 KB, patch)
2018-01-15 09:18 PST, Frédéric Wang (:fredw)
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Frédéric Wang (:fredw) 2017-11-24 04:21:04 PST
Created attachment 327541 [details]

In bug 179946, I'm mentioning that reconcileLayerPositionForViewportRect does not affect children deeper than the root node. Additionally, when the function is called for subframes, the "reconcile layer position" is still only applied from the root node, not the subframe node.

The attached patch tries to address that. However, as in bug 179946 I'm not sure about an effect of reconcileLayerPositionForViewportRect that I can test. I tried my patch with the experimental macOS async frame scrolling but still can not see any difference.
Comment 1 Frédéric Wang (:fredw) 2018-01-15 09:18:59 PST
Created attachment 331341 [details]
Patch (applies on top of bugs 173833 and 179946)

An alternative version applying on top of bugs 173833 and 179946. The test outputs the layer tree. But I'm still not sure how to exhibit a difference with the old code.