You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We just removed this condition, because we thought it is no longer needed. Unfortunately, that was a mistake and we still need to react only to transparent batches. Why?
On model.Document#event:change we check if proper characters have been put together, for example, we check if 1. was typed. If so, we open a new enqueueChange block, and inside it, we insert a list item.
However, the list item is inserted in another batch. What's more, the batch with 1. is sent before and separately to the batch with the list item.
So, in collaboration, a remote client first receives a batch that inserts 1. , the batch is handled (list item is inserted by auto format) and then it receives another batch, which also inserts list item. This causes a bug.
As I also mentioned, it will be enough to react only to transparent batches. Another solution would be to introduce another event (let's call it changesDone ha-ha-ha). That event would be fired after all change blocks are done. I will create a ticket to discuss it.
The text was updated successfully, but these errors were encountered:
I know, I know.
We just removed this condition, because we thought it is no longer needed. Unfortunately, that was a mistake and we still need to react only to
transparent
batches. Why?On
model.Document#event:change
we check if proper characters have been put together, for example, we check if1.
was typed. If so, we open a newenqueueChange
block, and inside it, we insert a list item.However, the list item is inserted in another batch. What's more, the batch with
1.
is sent before and separately to the batch with the list item.So, in collaboration, a remote client first receives a batch that inserts
1.
, the batch is handled (list item is inserted by auto format) and then it receives another batch, which also inserts list item. This causes a bug.As I also mentioned, it will be enough to react only to
transparent
batches. Another solution would be to introduce another event (let's call itchangesDone
ha-ha-ha). That event would be fired after all change blocks are done. I will create a ticket to discuss it.The text was updated successfully, but these errors were encountered: