Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 8fef2855838a2286018250ed68dad20cb1cee1f6
https://github.com/WebKit/WebKit/commit/8fef2855838a2286018250ed68dad20cb1cee1f6
Author: Wenson Hsieh <[email protected]>
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
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
