InputCommand loses selection attributes when selection is anchored to attribute beginning

[mlewand]

📝 Provide detailed reproduction steps (if any)

1. Open the classic editor example.
2. Select few words, e.g. "things on earth" and bold it.
3. Select word "things".

1. Execute editor.execute( 'input', { text: 'foobar' } ); in your JavaScript console.

✔️ Expected result

The inserted text keeps original styles (in this case bold).

❌ Actual result

The replaced part is not bold.

📃 Other details

This is a source of WebSpellChecker/wproofreader-ckeditor5#12 - as WSC team is using editor.execute('input', { text: 'text' }); call to make text modifications.

Reason for this is that we pick attributes from a new selection, after original part was removed:

ckeditor5/packages/ckeditor5-typing/src/inputcommand.js

Line 98 in 090c9f0

model.insertContent( writer.createText( text, doc.selection.getAttributes() ), selection );

• Browser: Any

---

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

[mlewand]

I have pushed i/7816 branch that contains an example fix (but no tests) for this issue.

[mlewand]

Surprisingly very little tests have failed after the change.

I'm marking this issue as a potential breaking change, as changing it will especially affect the case where you "overwrite" the entire node with an attribute (currently replaced content is plain text, whereas now it would inherit the attributes of a replaced text).

[Reinmar]

This was working this way by design. You can observe the same behavior upon typing in CKE5.

However, I noticed that both Pages, Word, and Google Docs inherit the selection styles in this case and I'm totally fine with changing this behavior on our side too.

[mlewand]

Should the type over behavior be still covered by this issue or should we extract it into a separate issue?

Reason why I am asking is that this dead simple fix that I proposed solves already the InputCommand (initial comment scope), but getting it to work with typing will be tirckier, it doesn't work out of the box. My assumption is that the mutation observers kick in late, after the initial content is removed without preserving the issue.

[oleq]

My assumption is that the mutation observers kick in late, after the initial content is removed without preserving the issue.

Once we switch to beforeinput this may change. So maybe let's wait for #8007 first?