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