Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 96ab975fa598b15fd457a525ac5c735259f08a7e
https://github.com/WebKit/WebKit/commit/96ab975fa598b15fd457a525ac5c735259f08a7e
Author: Wenson Hsieh <[email protected]>
Date: 2024-07-02 (Tue, 02 Jul 2024)
Changed paths:
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
Log Message:
-----------
Mitigate sporadic keyboard task queue deadlocks when pressing arrow keys when
editing
https://bugs.webkit.org/show_bug.cgi?id=276143
rdar://88371405
Reviewed by Abrar Rahman Protyasha.
Mitigate one reproducible source of hangs when pressing arrow keys when editing
in Mac Catalyst, to
modify the current selection. It's currently possible for UIKit to dispatch key
events before the
previous key event has been handled on Mac Catalyst (this is in contrast to
iPadOS or iOS, where key
events are only dispatched once the last event has been handled).
For arrow keys, this can end up triggering methods like
`-_moveLeft:withHistory:` before the
previous key event has been handled by the web content process. We subsequently
call back into UIKit
via `-selectionWillChange:` in this method, which then causes UIKit to block
the main thread while
it waits for the completion handler of the previously-dispatched key event to
be called. Of course,
this never happens because this completion handler must be called on the main
thread, and so we
permanently deadlock and eventually crash.
There are a number of architectural issues in this sequence of events that
cause this bug (most
egregiously, the way UIKit locks the main thread to wait for a completion
handler call, which can
only be run on the main thread). The divergence in behavior between iPad and
Catalyst which causes
new key events to be sent without waiting for previous key events to be
completed is also not ideal.
However, these are both pretty difficult to fix, especially in the short term.
Instead, we can work around this issue for now (and thereby mitigate the
most-easily-reproducible
scenario where the user just uses arrow keys to modify the selection) by
immediately rejecting key
events from being handled, if they're sent while a pending arrow key event is
still in flight. This
fixes the special case of this deadlock, where the `-interpretKeyEvent:` call
triggers selection
modification while any other key event is still pending.
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _internalHandleKeyWebEvent:withCompletionHandler:]):
Canonical link: https://commits.webkit.org/280598@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
