Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: e59b5d3cc487c7796cca696ac3a05b2f98b739b2
https://github.com/WebKit/WebKit/commit/e59b5d3cc487c7796cca696ac3a05b2f98b739b2
Author: Sam Sneddon <[email protected]>
Date: 2026-07-23 (Thu, 23 Jul 2026)
Changed paths:
M Source/WebKit/UIProcess/Automation/SimulatedInputDispatcher.cpp
Log Message:
-----------
REGRESSION(283790@main): the touch path didn't adopt mouseInteraction and no
longer works
https://bugs.webkit.org/show_bug.cgi?id=319610
rdar://182438327
Reviewed by BJ Burg.
The Touch branch of transitionInputSourceToState never adopted
283790@main's change to dispatch off b.mouseInteraction: it still
infers TouchDown/LiftUp/MoveTo purely from pressedMouseButton edges.
safaridriver's paired fix for the same bug stopped clearing
pressedMouseButton on pointerUp, relying on mouseInteraction alone to
signal Up, so pressedMouseButton now stays set across the whole
pointerDown/pointerUp pair. Since the Touch branch only emits LiftUp
when pressedMouseButton goes from set to unset, no LiftUp is emitted
for the pointerUp action itself; the touch stays held until the next
command (or the Release Actions reset keyframe) lifts it late and at
the wrong coordinate.
Port 283790@main's approach to the Touch branch, mirroring the
Mouse/Pen branch exactly: dispatch off b.mouseInteraction with no
pressedMouseButton-delta fallback. This makes the Up keyframe's
resolveLocation(origin=Pointer, location=(0,0)) resolve to the down
coordinate, so LiftUp now fires in place during the pointerUp action's
own keyframe transition.
* Source/WebKit/UIProcess/Automation/SimulatedInputDispatcher.cpp:
(WebKit::touchInteractionForMouseInteraction):
(WebKit::SimulatedInputDispatcher::transitionInputSourceToState):
Canonical link: https://commits.webkit.org/317834@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications