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