[webkit-changes] [WebKit/WebKit] 8fef28: [iOS] Several editing pasteboard tests fail when b...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 8fef2855838a2286018250ed68dad20cb1cee1f6
      https://github.com/WebKit/WebKit/commit/8fef2855838a2286018250ed68dad20cb1cee1f6
  Author: Wenson Hsieh <wenson_hsieh at apple.com>
  Date:   2024-06-14 (Fri, 14 Jun 2024)

  Changed paths:
    M Source/WebCore/platform/ios/PasteboardIOS.mm

  Log Message:
  -----------
  [iOS] Several editing pasteboard tests fail when built WebKit is binary compatible with system WebKit
https://bugs.webkit.org/show_bug.cgi?id=275494
rdar://129306120

Reviewed by Abrar Rahman Protyasha and Tim Horton.

When running tests on `safari-7618-branch` on iOS, the following 4 layout tests fail only in the
case where the built WebKit stack is binary compatible with the system WebKit version:

• editing/pasteboard/4930986-1-paste-as-quotation.html
• editing/pasteboard/4930986-2-paste-as-quotation.html
• editing/pasteboard/4930986-3-paste-as-quotation.html
• editing/pasteboard/paste-content-with-overflow-auto-parent-across-origin.html

This happens because since iOS 17.4, `nsattributedstringagent` is launched in response to a request
for `com.apple.flat-rtfd` data on the pasteboard in the following case:

1. `com.apple.flat-rtfd` data was not written explicitly to the pasteboard.
2. One or both of `public.html` or `com.apple.webarchive` was explicitly written to the pasteboard.

This attributed string agent links against the built WebKit stack via `__XPC_DYLD_FRAMEWORK_PATH`,
but because the `__XPC_` prefix only propagates the DYLD framework path override to XPC services
launched by `WebKitTestRunnerApp`, the web content process that's launched by this attributed string
agent ends up linking against the system WebKit stack instead of the built WebKit stack.

Normally, this results in `nsattributedstringagent`'s web content process terminating shortly after
launch due to binary incompatibilities with various IPC message identifiers, which causes code in
`PasteboardIOS.mm` that requests flat RTFD data from the pasteboard to fail (and return 0 bytes) in
the case where there's only `text/html` data on the pasteboard (and the flat RTFD data is therefore
synthesized by system frameworks). This, in turn, effectively disables the new UIKit pasteboard
attributed string coercion codepaths introduced in iOS 17.4, causes us to just read the raw
`text/html`, and thus allows the tests to pass because the round trip from markup to attributed
string and back would otherwise drops the `apple-style-span` class attribute.

However, if (by some miracle) the built WebKit stack is binary compatible enough with the system
version of WebKit that attributed string conversion succeeds, we end up reading an attributed string
from the system pasteboard in this case, which leads to different results due to the round tripping.

While it's not great that round tripping loses `apple-style-span`, it's also pretty bad (for
performance as well as testing sanity) that we even try to use `nsattributedstringagent` in this
scenario, since the HTML or web archive data already has full fidelity. To fix this, we instead
detect that the pasteboard contains a payload that we (WebKit) wrote ourselves when copying web
content, and use that as a hint to prefer HTML and web archive data over either RTF or flat RTFD.
Since any RTF/flat RTFD content we write to the pasteboard is derived from web content anyways, the
HTML and web archive representation will always be higher fidelity than their TextKit counterparts.

* Source/WebCore/platform/ios/PasteboardIOS.mm:
(WebCore::isTypeAllowedByReadingPolicy):

Also adopt `UniformTypeIdentifiers.framework` in a few more places while I'm refactoring this code,
to fix some would-be deprecation warnings due to using `kUTType*`.

(WebCore::supportedWebContentPasteboardTypesWhenCustomDataIsPresent):
(WebCore::Pasteboard::read):
(WebCore::Pasteboard::supportedWebContentPasteboardTypes):

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



To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications