[webkit-changes] [WebKit/WebKit] 9bf259: [UIAsyncTextInput] Keyboard incorrectly autocapita...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 9bf259e8d9e0193d6bbe8bd66259bf9d853dd538
      https://github.com/WebKit/WebKit/commit/9bf259e8d9e0193d6bbe8bd66259bf9d853dd538
  Author: Wenson Hsieh <wenson_hsieh at apple.com>
  Date:   2024-01-02 (Tue, 02 Jan 2024)

  Changed paths:
    A LayoutTests/editing/deleting/ios/no-autoshift-after-deleting-character-in-word-expected.txt
    A LayoutTests/editing/deleting/ios/no-autoshift-after-deleting-character-in-word.html
    M Source/WebKit/Shared/DocumentEditingContext.mm
    M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
    M Tools/TestWebKitAPI/cocoa/TestWKWebView.mm

  Log Message:
  -----------
  [UIAsyncTextInput] Keyboard incorrectly autocapitalizes after deleting backwards
https://bugs.webkit.org/show_bug.cgi?id=267003
rdar://120381357

Reviewed by Megan Gardner.

This bug was caused by the fact that autocorrection context requests with async text input enabled
broke after the changes in 272018 at main — in particular, because we don't pass the `Text` request
flag when converting from `WebKit::DocumentEditingContext` to `WKSETextDocumentContext` in
`-requestTextContextForAutocorrectionWithCompletionHandler:`.

This happened to work in my testing when `SERVICE_EXTENSIONS_TEXT_INPUT_IS_AVAILABLE` is set,
because the logic in `DocumentEditingContext::toPlatformContext` assumes that `Text` is specified,
if `AttributedText` isn't set. This was an unintentional departure from the shipping behavior, which
checked:

```
    if (options.contains(DocumentEditingContextRequest::Options::AttributedText)) {

        …

    } else if (options.contains(DocumentEditingContextRequest::Options::Text)) {

        …

    }
```

As such, we fix this by making the `SERVICE_EXTENSIONS_TEXT_INPUT_IS_AVAILABLE` codepath consistent
with the above logic, and pass in `DocumentEditingContextRequest::Options::Text` when using
`toPlatformContext`, when returning an autocorrection context in
`-requestTextContextForAutocorrectionWithCompletionHandler:`.

* LayoutTests/editing/deleting/ios/no-autoshift-after-deleting-character-in-word-expected.txt: Added.
* LayoutTests/editing/deleting/ios/no-autoshift-after-deleting-character-in-word.html: Added.

Add a layout test to exercise the bug fix.

* Source/WebKit/Shared/DocumentEditingContext.mm:
(WebKit::DocumentEditingContext::toPlatformContext):

Make this only set non-attributed text context strings in the case where the `Text` request flag is
specified, to match shipping behavior.

* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView requestTextContextForAutocorrectionWithCompletionHandler:]):
* Tools/TestWebKitAPI/cocoa/TestWKWebView.mm:
(-[WKWebView autocorrectionRectsForString:]):
(-[WKWebView autocorrectionContext]):
(-[WKWebView effectiveTextInputTraits]):
(-[WKWebView replaceText:withText:shouldUnderline:completion:]):

Drive-by cleanup around API test infrastructure, with async text input enabled:

-   Some of these codepaths were using `UI_ASYNC_TEXT_INPUT` instead of `UI_ASYNC_TEXT_INTERACTION`,
    effectively becoming dead code.

-   A couple of codepaths related to autocorrection context and rects weren't actually calling into
    the async text input codepaths as intended.

(wrap):
(-[WKWebView synchronouslyAdjustSelectionWithDelta:]):
(-[WKWebView selectTextForContextMenuWithLocationInView:completion:]):
(-[WKWebView handleKeyEvent:completion:]):

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