[webkit-changes] [WebKit/WebKit] 7d47c1: [iOS] WKContentView's paste configuration should o...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 7d47c1f87098be0b3c687e5ae1aa27b0c5b54428
      https://github.com/WebKit/WebKit/commit/7d47c1f87098be0b3c687e5ae1aa27b0c5b54428
  Author: Wenson Hsieh <wenson_hsieh at apple.com>
  Date:   2024-01-04 (Thu, 04 Jan 2024)

  Changed paths:
    M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
    M Tools/TestWebKitAPI/Tests/ios/UIPasteboardTests.mm

  Log Message:
  -----------
  [iOS] WKContentView's paste configuration should only contain valid UTIs
https://bugs.webkit.org/show_bug.cgi?id=267081
rdar://120446511

Reviewed by Aditya Keerthi.

We currently add `WebArchivePboardType` (whose raw value is `Apple Web Archive pasteboard type`) to
the list of acceptable UTIs when setting a `UIPasteConfiguration` on the content view. This can
cause a crash when attempting to show the edit menu in some third party apps (e.g. Gmail),
underneath UIKit code that assumes `-[UTType _typeWithIdentifier:allowUndeclared:]` will always
return a non-null value for each acceptable UTI.

UIKit is adding null checks in rdar://119912158 to handle this case gracefully, but we shouldn't be
adding these invalid UTIs in the first place. This patch splits `supportedRichTextPasteboardTypes`
into a separate `supportedRichTextPasteboardTypesForPasteConfiguration` helper that returns
`com.apple.webarchive` rather than `WebArchivePboardType`, and uses that when creating the paste
configuration; for compatibility with `-canPerformAction:withSender:`, we continue adding the legacy
`WebArchivePboardType` alongside the declared UTI in `supportedRichTextPasteboardTypes`.

Test: UIPasteboardTests.PasteConfigurationContainsValidUniformTypeIdentifiers

* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView setUpInteraction]):
(-[WKContentView supportedPasteboardTypesForCurrentSelection]):
* Tools/TestWebKitAPI/Tests/ios/UIPasteboardTests.mm:

We use a regex here instead of checking `-[UTType _typeWithIdentifier:allowUndeclared:]`, since that
SPI method actually returns a non-null result in the iOS simulator (as opposed to a real device,
where it returns `nil`). To make the test agnostic to this difference, we check whether or not the
UTI is valid by following the syntax rules in "Uniform Type Identifier Concepts" (on
developer.apple.com):

```
You may use the Roman alphabet in upper and lower case (A–Z, a–z), the digits 0 through 9, the dot
(“.”), and the hyphen (“-”). […] Uniform type identifiers may also contain any of the Unicode
characters greater than U+007F.
```

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