[webkit-changes] [WebKit/WebKit] 81896a: [iOS 17.4] Copying a relative URL in Reader mode a...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 81896aa61d54b15aff51c5480e318b42ff08d58a
      https://github.com/WebKit/WebKit/commit/81896aa61d54b15aff51c5480e318b42ff08d58a
  Author: Wenson Hsieh <wenson_hsieh at apple.com>
  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