Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 81896aa61d54b15aff51c5480e318b42ff08d58a
https://github.com/WebKit/WebKit/commit/81896aa61d54b15aff51c5480e318b42ff08d58a
Author: Wenson Hsieh <[email protected]>
Date: 2024-02-10 (Sat, 10 Feb 2024)
Changed paths:
M LayoutTests/platform/ios/editing/pasteboard/onpaste-text-html-expected.txt
M LayoutTests/platform/mac/editing/pasteboard/onpaste-text-html-expected.txt
M LayoutTests/platform/mac/fast/events/ondrop-text-html-expected.txt
M Source/WebCore/editing/markup.cpp
M Source/WebCore/editing/markup.h
M Source/WebCore/loader/archive/cf/LegacyWebArchive.cpp
M Tools/TestWebKitAPI/Configurations/TestWebKitAPI.xcconfig
M Tools/TestWebKitAPI/Tests/WebKitCocoa/CopyHTML.mm
Log Message:
-----------
[iOS 17.4] Copying a relative URL in Reader mode and pasting in Messages
inserts a safari-reader:// URL
https://bugs.webkit.org/show_bug.cgi?id=269143
rdar://122391840
Reviewed by Ryosuke Niwa.
Starting in iOS 17.4, Safari no longer writes `NSAttributedString` data
directly to the pasteboard.
Instead, we just write web archive data and HTML, which the system converts (on
paste) into an
`NSAttributedString` only if needed, using UIFoundation (…which uses an
offscreen WKWebView under
the hood, via `nsattributedstringagent`).
However, when copying a selected link with a relative HREF like `<a
href="/foo.html">…</a>` in
Safari reader, the reader document has a `base` element with an `href`
referencing the original
website URL, while the real document URL has a scheme of `safari-reader://…`.
When writing web
archive data to the pasteboard in Safari, we just write the markup `<a
href="/foo.html">…</a>` as-
is; when converting to an attributed string (e.g., when pasting in Messages) we
complete the
relative URL using the top document URL taken from the web archive, which still
uses a scheme of
`safari-reader://`, so resulting attributed string has a link attribute
pointing to a
`safari-reader://` URL instead of the HTTP URL.
To avoid this, we detect the fact that there’s a `base` element in the document
when creating web
archive data from the current selection, and prepend the `base` element to the
markup, under the
`head`; in doing so, we ensure that relative URLs will be completed using the
same `base` element
that was present in the document when copying.
Test: CopyHTML.SanitizationPreservesRelativeURLInAttributedString
* LayoutTests/platform/ios/editing/pasteboard/onpaste-text-html-expected.txt:
* LayoutTests/platform/mac/editing/pasteboard/onpaste-text-html-expected.txt:
* LayoutTests/platform/mac/fast/events/ondrop-text-html-expected.txt:
Rebaseline layout tests to account for the fact that the `meta` tag is now also
inserted below the
`head` element (as [noted in the
spec](https://html.spec.whatwg.org/multipage/semantics.html#the-meta-element)).
* Source/WebCore/editing/markup.cpp:
Rename `prependMetaCharsetUTF8TagIfNonASCIICharactersArePresent` to
`prependHeadIfNecessary`, and
make it append both, either or none of the `meta` and `base` elements
underneath a `head` element.
Like before, we only append `meta charset=UTF-8` on Cocoa in the case where the
text contains non-
ASCII characters, for compatibility with system NSPasteboard/UIPasteboard text
encoding treatment.
If the given `baseElement` is non-null, we'll additionally append the base
element (along with its
attributes) to the `head`. Note that if neither of the above elements are
needed, we'll just skip
appending a `head`.
(WebCore::serializePreservingVisualAppearanceInternal):
Add support for a new `PreserveBaseElement` option, which indicates whether or
not we should attempt
to preserve the base element, if it exists in the document containing the given
range. This is `No`
by default, and set to `Yes` only when generating web archive data from a
selected range in the
document to ensure that any completed relative URLs in the selected range point
to the same resource
in the web archive, as they previously did in the original document.
(WebCore::serializePreservingVisualAppearance):
(WebCore::sanitizedMarkupForFragmentInDocument):
* Source/WebCore/editing/markup.h:
* Source/WebCore/loader/archive/cf/LegacyWebArchive.cpp:
(WebCore::LegacyWebArchive::createFromSelection):
Pass in `PreserveBaseElement::Yes`. See above for more details.
* Tools/TestWebKitAPI/Configurations/TestWebKitAPI.xcconfig:
Drive-by fix: remove the redundant `WK_UNIFORM_TYPE_IDENTIFIERS_LDFLAGS`
setting, which was only
used to link against `UniformTypeIdentifiers` on iOS (but is now unnecessary,
since we already
unconditionally link `UniformTypeIdentifiers` in `OTHER_LDFLAGS`).
* Tools/TestWebKitAPI/Tests/WebKitCocoa/CopyHTML.mm:
Add an API test that simulates copying a relative URL (`/downloads`) in a
document with a `base` and
pasting in an app that converts the web archive data to `NSAttributedString`;
the resulting link URL
corresponding to `NSLinkAttributeName` in the attributed string should point to
the original URL
(`https://webkit.org/downloads`), instead of `file:///downloads`.
Canonical link: https://commits.webkit.org/274434@main
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
