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