I give up on this for now. I pushed my attempt to https://github.com/xwiki/xwiki-platform/commit/9a6064bf744d0c18f477dcb86193b2ed014cee7b . The problem is how to "serialize" the DOM selection. It's not easy because the output HTML that is converted to HyperJSON and then synced with the rest of the editors can be different from the actual content of the editor:
some elements are filtered out (e.g. empty elements, bogus BR tags)
some elements are transformed in the output HTML
Any serialization that relies on child node index (e.g. xpath) won't be able to cover all cases. Moreover, the complexity is that the selection is allowed not just inside a text node but:
between DOM nodes (e.g. after an EM tag when you use Ctrl+I to get out of the EM tag at the end)
inside read-only content that is not saved and thus not part of the content that is synchronized
Regarding the first point, it's actually the limitation of the text-based selection restore mechanism we have because you lose this information (caret between nodes) when serializing the selection to plain text.
For the second point I think a hybrid approach is needed, i.e. when the selection is inside the editable content (that is synced) use the selection transformed by the Chainpad patches, otherwise, if the selection is inside the real-only part (e.g. macro output) then use the current text-based (diff-based) selection restore mechanism we have.
Given this, I tried to "embed" the selection information in the edited content, so that it gets serialized along with the edited content in the output HTML. The problem with this approach is that the output HTML is going to change whenever the selection changes (even if there isn't any actually content change, just the user moving the caret around). If you don't notify ChainPad of these (selection-caused) changes, and you just push actual content changes (like I did) then you're going to get merge conflicts from ChainPad and diffDOM.
The remaining thing to try is to include the selection information in the synced content (embedded in the edited content, i.e. in the output HTML). But this needs some thinking:
how to embed the selection in the edited content (what kind of markers to use so that it doesn't break the HTML validity, and it doesn't affect the editing experience); in my experiment I used HTML comments, that should be allowed anywhere in the DOM, but if we want to highlight the selection of other editing users we need an element instead
how often to push selection-caused content changed
how to handle the case when the selection or one of its edges is inside some read-only content (like macro output)
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.