[webkit-changes] [WebKit/WebKit] f134a5: [iOS] Paste alert should not show up in WebKit app...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: f134a54c03b71e8e3c4da00af4612e28769cecdf
      https://github.com/WebKit/WebKit/commit/f134a54c03b71e8e3c4da00af4612e28769cecdf
  Author: Wenson Hsieh <wenson_hsieh at apple.com>
  Date:   2022-10-11 (Tue, 11 Oct 2022)

  Changed paths:
    M Source/WebKit/Shared/EditorState.cpp
    M Source/WebKit/Shared/EditorState.h
    M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
    M Source/WebKit/WebProcess/WebPage/WebPage.cpp
    M Tools/TestWebKitAPI/Tests/WebKitCocoa/PasteMixedContent.mm

  Log Message:
  -----------
  [iOS] Paste alert should not show up in WebKit apps when presenting the edit menu
https://bugs.webkit.org/show_bug.cgi?id=246364
rdar://100730751

Reviewed by Aditya Keerthi.

In r235079, we made it possible for the Paste action to show up in the callout bar (i.e. edit menu)
when the pasteboard only contains the `"com.apple.WebKit.custom-pasteboard-data"` type, as long as
the custom pasteboard data was written by the same origin. To achieve this, we inspect the contents
of the custom pasteboard data in `-canPerformActionForWebView:withSender:`, when determining whether
"Paste" is a valid action in the web view, which requires us to access pasteboard data before the
user has explicitly pasted.

However, in iOS 16, this now causes a programmatic paste prompt to (rightfully) show up, since we're
reading from the pasteboard outside of a user-driven paste. To mitigate this, we refactor the code
such that we'll return `YES` as long as the `"com.apple.WebKit.custom-pasteboard-data"` type is
present.

Note that this still means we'll avoid exposing custom pasteboard data across origins on iOS — just
that we now unconditionally show the Paste action when `"com.apple.WebKit.custom-pasteboard-data"`
is present, in order to avoid reading from the pasteboard.

While it's technically possible for us to preserve shipping behavior by writing a new pasteboard
type that contains the security origin string, I opted to avoid this approach, since it would allow
native apps to observe which websites the user had copied content from, *without* triggering a
system paste notification.

* Source/WebKit/Shared/EditorState.cpp:
(WebKit::EditorState::encode const):
(WebKit::EditorState::decode):
* Source/WebKit/Shared/EditorState.h:

Additionally remove `EditorState::originIdentifierForPasteboard`, now that it's unused.

* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView supportedPasteboardTypesForCurrentSelection]):
(-[WKContentView canPerformActionForWebView:withSender:]):
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::editorState const):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/PasteMixedContent.mm:
(TestWebKitAPI::PasteboardAccessChecker::PasteboardAccessChecker):
(TestWebKitAPI::PasteboardAccessChecker::didAccessPasteboard const):
(TestWebKitAPI::PasteboardAccessChecker::returnNil):
(TestWebKitAPI::TEST):

Adjust this API test to verify that `-canPerformAction:withSender:` now returns `YES`, and does not
attempt to read from the pasteboard in doing so.

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