[webkit-changes] [WebKit/WebKit] 72124d: [iOS] Software keyboard sometimes dismisses immedi...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 72124d79b53ff977057a41424093ef90017db5d9
      https://github.com/WebKit/WebKit/commit/72124d79b53ff977057a41424093ef90017db5d9
  Author: Wenson Hsieh <wenson_hsieh at apple.com>
  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