This is a tracking bug for implementing the following ScrollingCoordinator hit test regions in blink property trees:
1) Touch action regions
2) non-fast scrollable regions
3) main thread scrolling reasons
I think the subtasks for the scroll hit test regions are roughly:
1) Add rects to blink's scroll node (ScrollPaintPropertyNode) and set them in PaintPropertyTreeBuilder which is run during the pre-paint tree walk. This needs to be done without querying compositing state.
2) We then need to collect all rects for a given composited layer, including the descendant scroll node rects that were not composited. With --enable-blink-gen-property-trees, we know compositing decisions in PaintArtifactCompositor. When walking paint chunks for a given composited layer in PAC, collect all descendant non-composited scroll nodes in a vector. Then, map all of the scroll rects into the transform space of the composited layer using GeometryMapper.
3) Finally, set the combined scroll rect for a composited layer on either cc's scroll node or cc::Layer.
Tests.. Are there existing layout tests that cover these rects? If so, they need to pass with --enable-blink-gen-property-trees and third_party/WebKit/LayoutTests/FlagExpectations/enable-blink-gen-property-trees should be updated to reflect that the test passes. Maybe as a sanity check, DCHECK that the rects produced with this process are equal to the rects currently produced by ScrollingCoordinator?
I learned that we need to design this in a way that works with and without blink-gen-property-trees in order to not block Viz.
I think we'll need to slightly modify the above design. We'll still add the hit test structure to ScrollPaintPropertyNode (and later TransformPaintPropertyNode) but we'll need to implement the blink->cc hookup twice: once for the current codepath (ScrollingCoordinator), and a second time for the PaintArtifactCompositor codepath.
Looking on the bright side, this will let us test the new approach even before launching blink-gen-property-trees.
I have a patch [1] that force-enables BlinkGenPropertyTrees and found several tests that fail[2]. We should make sure these tests pass.
Here are some tests that fail due to no touch action support:
SitePerProcessHitTestBrowserTest.MainframeTouchEventRouting/2
../../content/browser/site_per_process_hit_test_browsertest.cc:2691: Failure
Expected equality of these values:
cc::kTouchActionNone
Which is: 0
render_widget_host->input_router()->AllowedTouchAction()
Which is: 63
SitePerProcessHitTestBrowserTest.SubframeTouchEventRouting/2
Expected equality of these values:
cc::kTouchActionNone
Which is: 0
child_render_widget_host->input_router()->AllowedTouchAction()
Which is: 63
Similarly, here's a failure due to non-fast scrolling regions:
SitePerProcessInternalsHitTestBrowserTest.ScrollNestedLocalNonFastScrollableDiv/0../../content/browser/site_per_process_hit_test_browsertest.cc:680: Failure
Expected: (div_scroll_top_start) != (div_scroll_top), actual: 0 vs 0
[1] https://chromium-review.googlesource.com/c/chromium/src/+/1058604
[2] https://ci.chromium.org/p/chromium/builders/luci.chromium.try/linux_chromium_rel_ng/98353
Summary: Implement touch action regions, non-fast scrollable regions, main thread scrolling reasons independent of compositing decisions (was: Implement touch action regions, non-fast scrollable regions, main thread scrolling reasons in blink property trees)
Adjusting the title a bit. The goal of PaintTouchActionRects is really to make ScrollingCoordinator work independently of compositing decisions. Today (pre-PaintTouchActionRects), ScrollingCoordinator sets data on GraphicsLayers which depend on compositing. We want to make ScrollingCoordinator work independently of compositing because in SPV2, we do not know compositing until after ScrollingCoordinator's work is done. PaintTouchActionRects is the project to move touch action regions and non-fast scrollable regions to paint.
Comment 1 by flackr@chromium.org
, Apr 26 2018Owner: sunxd@chromium.org
Status: Assigned (was: Untriaged)