| Summary: | [UI-side compositing] css3/scroll-snap/scroll-snap-drag-scrollbar-thumb-with-sticky.html fails | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Simon Fraser (smfr) <simon.fraser> |
| Component: | Tools / Tests | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW --- | ||
| Severity: | Normal | CC: | nmouchtaris, simon.fraser, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Local Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
|
Description
Simon Fraser (smfr)
2023-02-16 20:56:17 PST
This test drags a scrollbar thumb with mouse events, and then tests to see if the scroller scrolled to a snap point. This mouse handling happens on the webcontent main thread (ScrollableArea::doPostThumbMoveSnapping()) which does:
newOffset.setX(scrollAnimator->scrollOffsetAdjustedForSnapping(ScrollEventAxis::Horizontal, currentOffset, ScrollSnapPointSelectionMethod::Closest));
Without UI-side compositing, newOffset.setX.x ends up with 748. With UI-side compositing, it's zero.
The issue with UI-side compositing here is that doPostThumbMoveSnapping() runs before the web process has actually updated the ScrollableArea's X offset to 748, because this involves a round-trip through the UI process (via RenderLayer::requestScrollPositionUpdate(), coming back through AsyncScrollingCoordinator::updateScrollPositionAfterAsyncScroll().
|