[webkit-changes] [WebKit/WebKit] 2c2739: Selecting a link and pasting plain text changes te...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 2c273978ff638f8499aeae96669dab48628f472f
      https://github.com/WebKit/WebKit/commit/2c273978ff638f8499aeae96669dab48628f472f
  Author: Wenson Hsieh <wenson_hsieh at apple.com>
  Date:   2023-04-30 (Sun, 30 Apr 2023)

  Changed paths:
    A LayoutTests/editing/pasteboard/paste-text-in-link-expected.txt
    A LayoutTests/editing/pasteboard/paste-text-in-link.html
    M Source/WebCore/editing/ReplaceSelectionCommand.cpp

  Log Message:
  -----------
  Selecting a link and pasting plain text changes text in the link, but not the link href
https://bugs.webkit.org/show_bug.cgi?id=256134
rdar://16950226

Reviewed by Ryosuke Niwa.

When copying text and pasting over a selected link (i.e. `a` element with an `href`), we currently
replace the text node underneath the link without changing any of the link's attributes (namely,
`href`) — this leads to confusing behaviors (particularly in Mail) when attempting to replace a link
by pasting a URL, since the visible text underneath the link will change (e.g. "www.apple.com" →
"google.com") but the link itself will still take you to the original location (e.g. "www.apple.com"
in the previous example). While this matches Cocoa platform behavior in TextEdit, it's clearly
undesirable — see also, rdar://108701929.

This happens because we end up taking the `ReplaceSelectionCommand::performTrivialReplace` codepath
when pasting, where we simply swap out the text node's data with the pasted text.

While it might be nice to somehow keep the link element and replace the HREF to something that suits
the newly pasted text in this case, it's not clear we'd be able to always choose a sensible new URL,
which might lead to more inconsistent behaviors. With respect to other browser engines' behaviors in
this scenario on macOS (by pasting "www.google.com" over a link to "https://www.apple.com" with text
"www.apple.com"):

•   Blink has the same bug as we do, except *slightly* more egregious — the visible text in the link
    gains a scheme (becoming "http://www.google.com") when pasting, but the `href` still points to
    "http://www.apple.com".

•   Gecko simply replaces the link with newly inserted plain text, "www.google.com".

Out of all the existing major browser behaviors, Gecko's seems like the most sensible; this patch
adjusts our logic to match Gecko's, by bailing from the `performTrivialReplace` codepath in cases
where we're fully replacing the contents of an enclosing link.

Test: editing/pasteboard/paste-text-in-link.html

* LayoutTests/editing/pasteboard/paste-text-in-link-expected.txt: Added.
* LayoutTests/editing/pasteboard/paste-text-in-link.html: Added.

Add a new layout test to exercise the change.

* Source/WebCore/editing/ReplaceSelectionCommand.cpp:
(WebCore::fullySelectsEnclosingLink):

Add a helper method to return whether or not the selection exactly encompasses the enclosing link's
content, by checking that the endpoints of the selection range are equal to the positions before and
after the link element.

(WebCore::ReplaceSelectionCommand::performTrivialReplace):

Avoid the trivial replacement codepath if the selection encloses a link.

Canonical link: https://commits.webkit.org/263539@main