[webkit-changes] [WebKit/WebKit] 34606a: Copied rdar:// links lose their `href` after pasti...
Wenson Hsieh
noreply at github.com
Tue Dec 6 08:05:02 PST 2022
Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 34606a516d650d304b5ca5d3f2dd712d1aea58fb
https://github.com/WebKit/WebKit/commit/34606a516d650d304b5ca5d3f2dd712d1aea58fb
Author: Wenson Hsieh <wenson_hsieh at apple.com>
Date: 2022-12-06 (Tue, 06 Dec 2022)
Changed paths:
M Source/WebCore/editing/cocoa/WebContentReaderCocoa.mm
M Source/WebCore/editing/markup.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/PasteHTML.mm
Log Message:
-----------
Copied rdar:// links lose their `href` after pasting into Mail compose
https://bugs.webkit.org/show_bug.cgi?id=248765
rdar://101878956
Reviewed by Ryosuke Niwa.
When sanitizing pasted markup, we currently strip out all URL attributes that are not either HTTP-
family, or data URLs. Done in https://commits.webkit.org/197779@main, the intent was to prevent the
user from inadvertently leaking private information — in particular, local file paths — when pasting
HTML. However, this means that in many other scenarios (e.g. when pasting app-specific URL schemes,
or even when pasting other well-known non-HTTP-family schemes such as `mailto:`), these pasted links
end up being no longer useful. To fix this, we (slightly) relax this constraint to allow non-file
URLs to remain in the sanitized markup, such that we'll allow pasted custom URL schemes (such as
`rdar://` in the original bug report), but still avoid exposing pasted file paths.
I also considered two alternatives, below:
(1) Avoid sanitizing away URL attributes on links, if the text content of the link contains the URL
string. While this provides a nice balance between compatability and privacy (since the user-
visible pasted text already contains the URL), it isn't sufficient to fix the bug as originally
reported, which contains a `rdar://` link with user-visible text that does not match.
(2) Introduce SPI for Mail to adopt in compose, which would prevent us from sanitizing away non-file
URLs (or provide a list of safe URL schemes to preserve). I decided to not go with this approach
since this issue isn't limited to Mail compose, but rather any WebKit client, and even web apps
in the browser. I also didn't want to introduce another behavioral difference between Mail and
Safari (or other WebKit clients).
* Source/WebCore/editing/cocoa/WebContentReaderCocoa.mm:
(WebCore::WebContentReader::readHTML):
(WebCore::WebContentMarkupReader::readHTML):
See above for more details.
* Source/WebCore/editing/markup.cpp:
(WebCore::removeSubresourceURLAttributes):
Use destructuring syntax here to make the code a tiny bit easier to read.
* Tools/TestWebKitAPI/Tests/WebKitCocoa/PasteHTML.mm:
Augment and rename an existing API test to cover this scenario.
Canonical link: https://commits.webkit.org/257410@main
More information about the webkit-changes
mailing list