Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: a477452eb93ff56f535304cccb7b0acb9cad0698
https://github.com/WebKit/WebKit/commit/a477452eb93ff56f535304cccb7b0acb9cad0698
Author: Wenson Hsieh <[email protected]>
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
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
