[webkit-changes] [WebKit/WebKit] a47745: [iOS 17.4] ~11 layout tests debug assert in `-hand...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: a477452eb93ff56f535304cccb7b0acb9cad0698
      https://github.com/WebKit/WebKit/commit/a477452eb93ff56f535304cccb7b0acb9cad0698
  Author: Wenson Hsieh <wenson_hsieh at apple.com>
  Date:   2024-03-13 (Wed, 13 Mar 2024)

  Changed paths:
    M Source/WebKit/UIProcess/ios/WKContentViewInteraction.h
    M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm

  Log Message:
  -----------
  [iOS 17.4] ~11 layout tests debug assert in `-handleKeyEntry:withCompletionHandler:`
https://bugs.webkit.org/show_bug.cgi?id=270928
rdar://123028621

Reviewed by Abrar Rahman Protyasha.

The new debug assertion in `-handleKeyEntry:withCompletionHandler:` (which sanity checks that the
key event completion handler for an incoming event `e` is invoked with `e`) is sometimes hit when
running layout tests that send synthetic key events. This reveals an existing bug, wherein
`WKContentView`'s `_keyWebEventHandler` is replaced with another incoming ObjC block in the case
when async key events are invoked back-to-back, before the preceding key event's completion handler
has been called. This causes the latter key event handler to be called with the previous key event,
and also means that the previous key event handler won't ever be called.

In practice, this is not an issue because UIKit's `UIKeyboardTaskQueue` doesn't attempt to send the
next key event until the previous one has finished processing (i.e., WebKit has called the
completion block associated with the event); this is likely an artifact of how HID key events are
synthesized and dispatched in WebKitTestRunner.

However, the `BETextInput` protocol doesn't inherently require or enforce this invariant, so it
probably makes more sense for `WKContentView` to be robust for this scenario and call all incoming
key event handler completion blocks with their corresponding appropriate events. To ensure this, we
replace the current `_keyWebEventHandler` instance variable with a vector of events and completion
blocks. This allows us to store multiple completion blocks if needed (for each key event that's
currently in-flight), and invoke the correct event handler in response.

* Source/WebKit/UIProcess/ios/WKContentViewInteraction.h:
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:

Replace `_keyWebEventHandler` with `_keyWebEventHandlers`, a `Vector` of `WebEvent`s and completion
handler blocks. See above for more details.

(-[WKContentView cleanUpInteraction]):
(-[WKContentView _cancelPendingKeyEventHandlers:]):
(-[WKContentView resignFirstResponderForWebView]):
(-[WKContentView _internalHandleKeyWebEvent:withCompletionHandler:]):
(-[WKContentView _didHandleKeyEvent:eventWasHandled:]):
(-[WKContentView _cancelPendingKeyEventHandler]): Deleted.

Canonical link: https://commits.webkit.org/276062@main



To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications