Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 72124d79b53ff977057a41424093ef90017db5d9
https://github.com/WebKit/WebKit/commit/72124d79b53ff977057a41424093ef90017db5d9
Author: Wenson Hsieh <[email protected]>
Date: 2024-12-10 (Tue, 10 Dec 2024)
Changed paths:
A
LayoutTests/fast/events/touch/ios/focus-textarea-on-touchstart-expected.txt
A LayoutTests/fast/events/touch/ios/focus-textarea-on-touchstart.html
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/WebPage.messages.in
M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm
Log Message:
-----------
[iOS] Software keyboard sometimes dismisses immediately when focusing
elements in the Pearson TestNav app
https://bugs.webkit.org/show_bug.cgi?id=284346
rdar://134957760
Reviewed by Abrar Rahman Protyasha.
Avoid treating a tap as a synthetic click in the following scenario:
- The page adds a `touchstart` event listener which triggers main frame
scrolling (either directly
or indirectly, by focusing an editable element).
- The user taps the element with the above `touchstart` listener, and the web
view scrolls.
- When the tap gesture ends, the synthetic tap gesture fires, triggering a
synthetic click over
the new content underneath the user's finger (after scrolling).
In the context of TestNav, this causes the keyboard to (sometimes) immediately
dismiss when tapping,
as the `textarea` immediately focuses itself underneath `touchstart`, which may
induce scrolling to
reveal the focused element.
To mitigate this, we add a heuristic to detect when the potential tap location
differs significantly
from the location of the initial location of the user's touch, relative to root
view coordinates; if
so (and the new hit-tested potential tap node differs from the node at the
prior touch start
location), we simply ignore the potential tap and avoid treating it as a
synthetic click.
* LayoutTests/fast/events/touch/ios/focus-textarea-on-touchstart-expected.txt:
Added.
* LayoutTests/fast/events/touch/ios/focus-textarea-on-touchstart.html: Added.
Add a layout test to exercise this scenario.
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::didBeginTouchPoint):
* Source/WebKit/UIProcess/WebPageProxy.h:
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _touchEventsRecognized]):
Send the touch start location to the webpage alongside this IPC message.
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::didBeginTouchPoint):
Keep track of the last touch start location in `m_lastTouchLocationBeforeTap`.
The lifecycle of this
member variable is (unfortunately) a bit finnicky, but it's guaranteed to be up
to date (as its name
suggests) before the next potential tap, where it's reset. The reason this
can't always be cleared
underneath `didReleaseAllTouchPoints()` is that the tap gesture is recognized
after the user ends
all touches, so `m_lastTouchLocationBeforeTap` would already be reset by the
time we need to consult
it in `potentialTapAtPosition`.
(WebKit::WebPage::didCommitLoad):
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKit/WebProcess/WebPage/WebPage.messages.in:
* Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::potentialTapAtPosition):
Add a simple heuristic to reject tap gestures as synthetic clicks (see
description above for more
details).
Canonical link: https://commits.webkit.org/287608@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
