I fixed the problem locally for the case when the caret is in the middle of some text, and you want to start typing bold for instance, but while testing this I discovered another issue: if your caret is at the start / end of the line and the line starts / ends with styled text (e.g. bold text) and you want to get out of the style (e.g. by pressing Ctrl+B to "remove" the bold style from the start / end of the line) you can't as long as there are remote changes coming. The root problem is that the code that restores the selection after a remote patch is applied doesn't support placing the caret at the start / end of the line outside the style. Here's an example:
<p><em>italic</em> other</p>
The following happens:
the caret is initially inside the <em> tag, at the start of the "italic" text
you press Ctrl+I to move the caret before the <em>
a remove patch is received
the selection is saved
the patch is applied
the selection is restored => here the caret ends up again inside the <em> tag at the start of the "italic" text, because the code restoring the selection thinks it doesn't make sense to have the caret between <p> and <em> and so it moves to the first text node inside the <em>. Changing this code is not trivial...
To fix this problem, I'll try to implement the following:
whenever there is a local change, save the selection relative to the HyperJSON content that is being synchronized by ChainPad (i.e. convert the DOM selection to a text / character selection for the HyperJSON)
transform the saved text selection using the received remote patches (which are text level patches) => this will remove the need to perform a diff between the local and the remote content to restore the selection, since we know diffing is slow
after remote patches are applied on the edited content, convert the transformed text selection (HyperJSON) to a DOM selection and update the editor selection
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.