microsoft / roosterjs

roosterjs is a framework-independent javascript rich text editor.
Other
1.15k stars 156 forks source link

Pasting inline text generates new HTML node #2246

Closed william57m closed 5 months ago

william57m commented 9 months ago

Describe the bug In the context of Viva Engage, we have an at mention feature, when we type "@" character followed by a name, it opens a suggestions list. We are using a plugin that listen for "@" and catch the text attached to @.

Typing text naturally generates a single HTML node

type

However, pasting text, generates a new HTML node.

paste

That cause our feature to break since we cannot catch the actual text that comes after the "@" character.

To Reproduce Try in the playground https://microsoft.github.io/roosterjs/index.html#event

Type "@brian" and inspect the element, you will see one node. Type "@" and paste "brian" and inspect the element, visually it looks the same, but you will see 2 nodes ("@" and "brian")

Expected behavior When inline text is paste, keep it in the same node.

Thanks in advance for any help.

JiuqingSong commented 9 months ago

It is not guaranteed to have a single text node in any places. You can use the following ways to see the text before:

  1. editor.getPositionContentSearch(). It will return a helper class that can give you text before the cursor
  2. Use Content Model to get the text mode before current selection marker.
haven2world commented 9 months ago

I'm wondering if node.normalize() helps here? Could we execute node.normalize() at some moments like after paste, setContent, or before generate content model?

william57m commented 9 months ago

@JiuqingSong I understand it's not guaranteed depending of what you paste, but I feel like a simple string with no formatting should not generate a new node. I tried in different editor, contenteditable, draftjs, ckeditor, quill... and they all behave the same way. RoosterJS seems to be the exception here, it doesn't seems correct to me but I may be wrong.

I'm not sure if our @mention feature should handle that differently, it could for sure, to be more robust and handle those splitted node, but is it the right thing? I'm a bit shared, because a real node split may mean that we should not handle @mention? I'm not sure honestly, I probably need more input to process that.

JiuqingSong commented 9 months ago

@haven2world is right. If you really want to merge those nodes, you can call node.normalize(). Here node can be either a parent node of the text nodes or the root level DIV element.

william57m commented 9 months ago

@JiuqingSong is it something we can call from our side at any point? We have a PastePlugin to handle some Copy Paste from different text format, do you think it should happen here? Or @haven2world was maybe referring to call that from your side?

JiuqingSong commented 5 months ago

Fixed in v9