Bug 252454 - [UI-side compositing] css3/scroll-snap/scroll-snap-drag-scrollbar-thumb-with-sticky.html fails
Summary: [UI-side compositing] css3/scroll-snap/scroll-snap-drag-scrollbar-thumb-with-...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: WebKit Local Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2023-02-16 20:56 PST by Simon Fraser (smfr)
Modified: 2023-02-16 21:00 PST (History)
3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Fraser (smfr) 2023-02-16 20:56:17 PST 
css3/scroll-snap/scroll-snap-drag-scrollbar-thumb-with-sticky.html fails with UI-side compositing.
Comment 1 Radar WebKit Bug Importer 2023-02-16 20:56:44 PST 
<rdar://problem/105579303>
Comment 2 Simon Fraser (smfr) 2023-02-16 21:00:19 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().