Commit de1f82a
committed
fix(unique-id): do not attempt to append to y-sync plugin transactions
This is because of a bug that we've had for a while, but I was never able to trace down.
- We set an initial block id for the initial content (always "initialBlockId" when collaboration is detected)
- `y-sync` replaces the document with what it "sees" in the `Y.XmlFragment` we gave it
- This causes a transaction to replace the initial content (replacing it with an empty document with a `blockContainer` containing an id of `null`)
- The unique id plugin sees this & attempts to correct the missing id, issuing a new transaction
- This means there is now a write to the `Y.XmlFragment`\
This write can happen independently to the provider actually synchronizing the content.
Meaning, that the `Y.XmlFragment` and `tr.doc` are out of sync when `y-prosemirror` attempts to [restore the selection](https://github.com/yjs/y-prosemirror/blob/ef35266d660c3cd76a491fde243b0c6bee25d585/src/plugins/sync-plugin.js#L634).
This is ultimately because `y-prosemirror` is listening to the Y.Doc _after_ it already is accepting the change. Which is totally valid, but ProseMirror doesn't offer a great way to keep these values in-sync.
The fix here is to just stop the unique-id extension from attempting to amend any `y-prosemirror` transactions. Ultimately, the remote editor should have already written the correct ID (since to the remote editor, it was the local editor - therefore, the unique-id extension should have run).1 parent eecbca5 commit de1f82a
1 file changed
+8
-0
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
130 | 130 | | |
131 | 131 | | |
132 | 132 | | |
| 133 | + | |
133 | 134 | | |
134 | 135 | | |
135 | 136 | | |
136 | 137 | | |
| 138 | + | |
| 139 | + | |
| 140 | + | |
| 141 | + | |
| 142 | + | |
| 143 | + | |
| 144 | + | |
137 | 145 | | |
138 | 146 | | |
139 | 147 | | |
| |||
0 commit comments