This issue has been created
There are 2 updates.
 
 
XWiki Platform / cid:jira-generated-image-avatar-1be3b865-b535-46d7-8d96-8739e08b7b68 XWIKI-24800 Open

The WYSIWYG editor sometimes doesn't join the realtime collaboration session

 
View issue   ยท   Add comment
 

Issue created

 
cid:jira-generated-image-avatar-3855ea1d-1678-4ba1-b1b6-317248970943 Vincent Massol created this issue on 03/Sep/26 22:24
 
Summary: The WYSIWYG editor sometimes doesn't join the realtime collaboration session
Issue Type: cid:jira-generated-image-avatar-1be3b865-b535-46d7-8d96-8739e08b7b68 Bug
Affects Versions: 18.1.0
Assignee: Unassigned
Components: Realtime
Created: 03/Sep/26 22:24
Priority: cid:jira-generated-image-static-major-775677ee-3061-471f-b7e9-cb56f9b8a109 Major
Reporter: Vincent Massol
Description:

Steps to reproduce

  1. Make sure realtime collaboration is enabled and the "Allow Realtime Collaboration" checkbox is checked.
  2. Edit a page with the WYSIWYG editor (standalone or in-place edit mode).
  3. Alternatively, change the document syntax while editing, which destroys and recreates the editor.

Expected result

The editor joins the realtime collaboration session: the realtime toolbar is displayed, the "Allow Realtime Collaboration" checkbox stays checked and the changes are synchronized with the other users editing the same page.

Actual result

Once in a while the editor doesn't join the realtime session: the realtime toolbar is missing, the standard "Save & View / Save / Preview / Cancel" button bar is displayed instead, and the "Allow Realtime Collaboration" checkbox appears unchecked. The user keeps editing as if realtime collaboration were disabled, so their changes are not shared with the other users editing the same page, and they don't see the changes made by those users either.

The failure is silent: nothing is thrown and no notification is displayed, so the only hint the user gets is the missing realtime toolbar.

This is a race, so it can happen on any editor load, but it is much more likely when the editor is recreated while the page stays loaded (e.g. after a document syntax change), because the RequireJS modules and the Netflux WebSocket are already warm and the realtime bootstrap then only costs two REST round trips, while the new editor still has to load its iframe.

Cause

CKEDITOR.plugins.add('xwiki-realtime').init() runs on pluginsLoaded, but editor.mode is only assigned much later, from within CKEDITOR.editor.prototype.setMode(), once the mode creator (the WYSIWYG iframe) has finished loading. The initial join does:

editor._realtime.connect = async () => {
  if (editor.mode !== 'wysiwyg') {
    // Realtime collaboration is supported, but we can't join until the user switches to WYSIWYG mode.
    return true;
  }
  ...
};
return editor._realtime.connect();

That guard is meant to detect the Source mode, but it also matches "the editing mode is not set yet". So whenever the realtime bootstrap completes before the editing mode is loaded, the editor silently gives up on joining the session, with realtimeSupported still true. None of the mode change handlers registered afterwards can recover from it, because there is no Source to WYSIWYG switch to react to.

The guard was added by XWIKI-23985, first released in 18.1.0.

Notes

This is also what makes RealtimeWYSIWYGEditorIT#syntaxChange flicker on CI. See XWIKI-24287 for the CI failure artifacts (screenshot and VNC recording), and https://github.com/xwiki/xwiki-platform/pull/6298 for the full analysis and the proposed fix.

 
 

2 updates

 
cid:jira-generated-image-avatar-3855ea1d-1678-4ba1-b1b6-317248970943 Changes by Vincent Massol on 03/Sep/26 22:24
 
Fix Version: 18.8.0-rc-1
Assignee: Vincent Massol