[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