Joining the realtime collaboration session waited for the initial synchronization with no timeout. The Yjs WebSocket provider retries the connection forever, because our end-point closes with codes it treats as retriable. So when the connection couldn't be established, the editor was never displayed, and the realtime toolbar wasn't created. In-place, the edit mode was entered with an empty content area. A join that failed with an error (e.g. the current user details couldn't be retrieved) also stayed cached, so the editor couldn't join again on the same page.
Fix
A connection that can't be established is now handled like a connection lost in the middle of a realtime session:
The editor stops waiting for the initial synchronization when no connection is established within 5 seconds, and joins the realtime session disconnected. The editor is displayed and the realtime toolbar shows "Disconnected". No notification is displayed, since the toolbar already shows the connection status.
While a connection is established but the server history is still being received, it keeps waiting. Initializing the content locally at that point would conflict with the session it's about to join.
The user can edit and save while disconnected, because saving doesn't depend on the collaboration server:
Done and Summarize & Done stay enabled, and the Save & Continue shortcut key works.
The content is auto-saved.
The created revisions are listed in the versions dropdown.
This applies only to BlockNote. The CKEditor and wiki realtime editors still disable saving while disconnected, because they become read-only.
The editor keeps trying to connect in the background. Once connected (thanks to XWIKI-25435):
if no one else is editing, the local content and changes are shared and the realtime session continues;
if someone else started editing the page meanwhile, the synchronization is stopped and the toolbar warns that the changes are not shared anymore, instead of duplicating the content.
A failed join is no longer cached, so joining again retries. If the collaboration session can't be created at all, the editor is displayed without realtime collaboration.
Limitations
A version saved while disconnected is not announced to the other users editing the page, so their next save may hit a merge conflict.
If someone else started editing the page before the connection was established, the local changes are kept but not merged into their session (same limitation as XWIKI-25435).
When WebSockets can't work at all (e.g. behind a proxy without WebSocket support), the editor keeps retrying (every 2.5 seconds at most) for the whole editing session, as it does after a connection loss.
Tests
Unit tests for the connection timeout, the auto-save start while disconnected, the join retry and the toolbar save actions. There are also three new reconnect scenarios against a fake room mimicking the XWiki end-point:
an empty room;
a session started by someone else before we initialized the content;
a session started by someone else after we did.
New functional test CollaborationIT#editWhileCollaborationServerIsUnreachable:
Loading the editor with the collaboration server unreachable.
Saving while disconnected, with the revision listed in the versions dropdown.
Reconnecting, after which a second user sees the changes and both users see each other.
The whole CollaborationIT passes (12/12).
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
