BUG: editing/replacing the text inside of a link
Sphenox opened this issue · 8 comments
GrapesJS version
- I confirm to use the latest version of GrapesJS
What browser are you using?
Chrome v122
Reproducible demo link
https://grapesjs.com/demo.html
Describe the bug
How to reproduce the bug?
- Open demo
- Create a text, with a link in it
- edit text with the default RTE
- select the whole link
- type anything, to replace the text of the link
What is the expected behavior?
When you type something, it should continue to write inside the link.
You can edit the text of links that contain only one character.
What is the current behavior?
Currently only the first character gets written inside the link. From the 2nd character onwards, the cursor isn't in the link anymore, so the text gets inserted right after the link. There is also no way to edit links, with only one character in it, so you have to delete the whole link after this behavior occures.
Code of Conduct
- I agree to follow this project's Code of Conduct
Just to clarify, you are referring to the selection of and editing of the text within the link behaving abnormally like this?
Yeah, excactly as shown in the video you provided.
Okay, I can confirm I am having the same issue. Probably related to the text selection point in the RTE (a guess).
Let's route @artf in on this and see if he has any insights to add.
Unfortunately, this is how the default contenteditable works 🤷♂️ (you can reproduce the same behavior there).
The only alternative here is to avoid the built-in RTE (which will be always limited to the native behavior).
@artf Let's keep this one open. I can't reproduce with a standard contenteditable as mentioned, and I want to try correcting this behavior.
@bernesto I don't know if it helps, but I only noticed this behaviour because I updated the GrapesJS version I was using. Before, I used v0.17.XX, don't remember the excact release.
Before the update, the RTE didn't behave like this.
Before the update, the RTE didn't behave like this.
@Sphenox I see the same behavior here: https://jsfiddle.net/3wtjpcro/4/
@bernesto FYI
contenteditable.mp4
@artf, you're right again. Whitespace in the node matters. If the text butts right up to the closing node, the first keystroke replaces the text, the next keystroke exits the node, if not, it works as one would expect.
There is an old thread about this (https://github.com/w3c/editing/issues/1560), specifically in webkit and blink, and how they work this way. One of the authors of CKEditor 5 was there, and basically said you have to build an abstraction layer to fix this behavior which is a total PITA in our case.
@Sphenox I'd say that this issue probably existed in the prior release as well from what I read. And, I's also say is likely be too much of a project to build that level of abstraction vs. just using an RTE that already has it built in.