We were showing the old edit mode toolbar right away.
The realtime WYSIWYG editor plugin was trying (repeatedly, in the background) to connect to the realtime session.
The user could edit and save.
After:
We hide the old edit mode toolbar right away, in order to avoid the UI flickering described in XWIKI-23233
We wait for the edit mode to be ready before showing the new toolbar.
The edit mode is ready after we connect to the realtime session; if the connection can't be established we try again, and again, keeping the edit mode in loading state, so the user can't edit or save.
The problem is that:
the connection / retry fails if the WebSocket (upgrade) request is blocked or forbidden, for instance, but that's not what happens in practice, e.g. when you have an HTTP proxy in front of XWiki that is not properly configured: in this case the browser appears to quickly connect and disconnect from the WebSocket end-point. This makes the ``netflux-client`` JavaScript library we use to communicate with the Netflux WebSocket end-point to try again and again..
Marius Dumitru Florea on 05/Aug/25 14:12
This is a regression introduced by XWIKI-23233.
*Before*:
* We were showing the old edit mode toolbar right away. * The realtime WYSIWYG editor plugin was trying (repeatedly, in the background) to connect to the realtime session. * The user could edit and save.
*After*:
* We *hide* the old edit mode toolbar right away, in order to avoid the UI flickering described in XWIKI-23233 * We wait for the edit mode to be ready before showing the new toolbar. * The edit mode is ready after we connect to the realtime session; if the connection can't be established we try again, and again, keeping the edit mode in loading state, so the user can't edit or save.
The problem is that: * the connection / retry fails if the WebSocket (upgrade) request is blocked or forbidden, for instance, but that's not what happens in practice, e.g. when you have an HTTP proxy in front of XWiki that is not properly configured: in this case the browser appears to quickly connect and disconnect from the WebSocket end-point. This makes the `` {{netflux-client``}} JavaScript library we use to communicate with the Netflux WebSocket end-point to try again and again.. * {{netflux-client}} library has no timeout or max retries configuration, so it tries to connect indefinitely
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
