[webkit-changes] [WebKit/WebKit] 96ab97: Mitigate sporadic keyboard task queue deadlocks wh...

[Wenson Hsieh]

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