Link UI: Changing link text can modify the wrong text #41771
Labels
[Feature] Link Editing
Link components (LinkControl, URLInput) and integrations (RichText link formatting)
[Package] Block editor
/packages/block-editor
Description
When editing the text of an existing link, sometimes the wrong text can be edited because a simple search and replace disregarding the active selection is done.
I believe the origin of this was #33849.
Step-by-step reproduction instructions
a b c a
a
, at the end of the text, press the link button to create a link, type in a url likeexample.com
and press enter. You should now have texta b c a
with the seconda
linked.a
by selecting with the mouse.a
toz
and press enter.a b c z
, because I was editing the link on the seconda
.z b c a
, because it does find and replace on the text of the link.Should be easier to understand in the screen recording.
Screenshots, screen recording, code snippet
Contrived example (word boundary)
Peek.2022-06-16.12-48-link-bug.mp4
Contrived example (within word)
Peek.2022-06-16.12-51-link-bug-2.mp4
For a less contrived example, imagine editing a word that was used twice or more in a long paragraph.
Environment info
982cfc7 from 2022-06-16 on trunk branch in wp-env.
Also seen on production wp.com on 2022-06-16.
I tried on earlier versions, going back to 2022-01-01 and still saw the behavior back then.
Please confirm that you have searched existing issues in the repo.
Yes
Please confirm that you have tested with all plugins deactivated except Gutenberg.
Yes
Mechanisms
The behavior is caused by this line:
gutenberg/packages/format-library/src/link/inline.js
Line 158 in 982cfc7
In the case of
a b c a
with the seconda
selected, and changing the text toz
, the replace call seesvalue
with.text
ofa b c a
, and runs a replace on it, looking fora
, and changes the first one it finds; even if it's not what I have selected.The call to it does have the selection information:
One idea I had was to make something like
replaceInSelection
, which does the same asreplace
, but only considers text within the start-end range. However, I know so little about gutenberg that I don't know if this is a good approach.The text was updated successfully, but these errors were encountered: