Ckeditor5: Pasting plain text on link breaks link

[jodator]

📝 Provide detailed reproduction steps (if any)

1. Use an example in docs (ie Classic editor).
2. Create a link (ie on "example")
3. Copy text without formatting (ie "foo").
4. Put the cursor inside the link (ie "exam|ple").
5. Use paste or plain-text paste.

✔️ Expected result

The link is set on whole text (ie on "examfoople")

❌ Actual result

The Pasted text breaks the link apart:

📃 Other details

cc @cksource/ckeditor-5-triage

• Browser: any (Firefox/Chrome tested)
• CKEditor version: master @ iteration36

---

If you'd like to see this fixed sooner, add a 👍 reaction to this post.

[jodator]

@Reinmar it works on the current docs:

[Reinmar]

Let's have this bisected. It's semi-serious. It's not a big UX issue, as it worked this way for the last 4 years. However, it's a pity that we broke something that we have just fixed in the last iteration.

@jodator, could you bisect it?

[mlewand]

Reason for this is that pasting as plain text clears anything except formatting attributes:

https://github.com/ckeditor/ckeditor5/blob/0632d06837a5cb80e7a3fb986253655a0b321391/packages/ckeditor5-clipboard/src/clipboard.js#L123

It was introduced as a part of recent paste as plain text improvements.

[Reinmar]

I don't understand. We were going in the direction to keep all the formatting on plain text paste. Not lose it. So, if we changed anything it should change it so we keep the formatting.

[Reinmar]

The good thing is that this is broken only for links. So, I wouldn't consider this a release blocker and I can also understand how we missed that (since this works for other attributes). So, from my side, no alarm :D

[Reinmar]

cc @cksource/ckeditor-5-triage (testing, as above it did not work)

[jodator]

cc @cksource/ckeditor-5-triage (testing, as above it did not work)

Looks like there's no such team (not highlighted).

The first bad commit is: cb08c3e.

[mlewand]

Yea, I guess that all attributes should be preserved - it's enough to remove the filter function.

It will change https://github.com/ckeditor/ckeditor5/blob/0632d06837a5cb80e7a3fb986253655a0b321391/packages/ckeditor5-link/tests/linkediting.js#L1256 though, so we'll need to decide whether we're ok with this or not (edit: that's the same thing I referenced in the commit message 😂).

I think we should revisit it at the start of next iteration.

[Reinmar]

Looks like there's no such team (not highlighted).

We need to cc teams from the respective orgs (@ckeditor or @cksource). I fixed that in our notes.

[jodator]

It will change

At first glance, it looks like different cases:

1. First case: a collapsed selection.
2. The second case: would be plain-text pasting inside the selection (inside, touching start, touching end).
3. The third (the linked one): a selection that fully covers the attribute range.

ps.: I didn't check the rest of the tests if the above cases are covered.

[Reinmar]

To be checked:

• Formatting vs other attributes (link, mention).
• Pasting in the middle of that content vs at the end/start of it (interesting scenario in case of mentions: what happens when you paste at the end of an existing mention).

[mlewand]

Another feature that was not mentioned and we should care about is restricted editing.

I checked how other text editors handle pasting plain text in relation to links and both Word and GDocs are consistent: link is removed only when pasting with link entirely selected. Otherwise the link is preserved.

In fact leaving non-formatting attributes when pasting plain text has some sense:

• Restricted editing is based on text attributes and you definitely want to keep _restricted editing exception_ marking then pasting a plain text in an existing exception field.
• Link inheriting also is the expected behavior.

As for mentions, their attribute is theoretically inherited but is then filter out by the mentions plugin (I'm assuming this is where its post-fixer kicks in).

PR with fix in #8272.