[webkit-changes] [WebKit/WebKit] 3a4f8b: [iOS] Swiping back in an HTML Note with the keyboa...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 3a4f8bd950259fd1e2723539bad7434ccbbdf606
      https://github.com/WebKit/WebKit/commit/3a4f8bd950259fd1e2723539bad7434ccbbdf606
  Author: Wenson Hsieh <wenson_hsieh at apple.com>
  Date:   2024-01-29 (Mon, 29 Jan 2024)

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

  Log Message:
  -----------
  [iOS] Swiping back in an HTML Note with the keyboard presented causes SpringBoard to crash
https://bugs.webkit.org/show_bug.cgi?id=268334
rdar://121139498

Reviewed by Aditya Keerthi.

As a part of `BETextInput` adoption, we stopped relying on support from various private protocols
including `UITextInputMultiDocument`, which allows UIKit to `-_preserveFocusWithToken:destructively:`
and `-_restoreFocusWithToken:`. This was previously used to keep DOM elements focused while the web
view lost first responder status, during credential AutoFill, if the user searches for other
passwords. However, now that AutoFill UI in web views in third party apps is entirely managed by
`SafariViewService`, we no longer lose first responder anyways, so we don't need to adopt this SPI.

However, there is a corner case in Notes where, when performing a swipe navigation controller
transition while the web view is first responder and `-_editable` (in the WebKit SPI sense), we
relied on this SPI to keep the web view focused even as it temporarily loses first responder status
during the swipe transition. In iOS 17.4, we no longer preserve focus, which means that we'll end up
dispatching a blur event on the body.

This, in turn, causes Notes' injected JavaScript to post a message back to the UI process telling it
to make the web view non-editable. However, while this is happening, UIKit tells the web view to
become first responder again during the swipe transition, which (after an activity state update)
causes Notes to make the web view `-_editable` once again, underneath `WKInputDelegate` methods.
This endless loop of:

(UI Process)    Web view becomes editable, dispatching a message to the web process.
(Web Process)   Body is blurred, posting a message to the UI process.
…
(UI Process)    Web view receives posted message, and makes the web view non-editable.
(Web Process)   Body is focused as a result of enabling full-page editability, starting an input
                session and sending ElementDidFocus to the UI process.

...causes the keyboard to be presented and dismissed back-to-back so frequently, that SpringBoard
itself eventually crashes due to excessive memory use.

Mitigate this by restoring pre-iOS 17.4 behavior and conforming to `UITextInputMultiDocument`, but
only for WebKit SPI clients that set the `-_editable` flag on `WKWebView`. Notably, this excludes
Safari.

* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _didChangeWebViewEditability]):

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