Details
-
Bug
-
Resolution: Unresolved
-
Critical
-
16.10.5
-
Windows 11 Pro, Edge 136, using an instance of XWiki 16.10.8 on MariaDB 11.6, Tomcat 9.0.104
-
Unknown
-
Description
Steps to reproduce
- Disable the Realtime feature (from Administer Wiki > Editing > WYSIWYG Editor, by adding xwiki-realtime to the Disabled Plugins)
- Create a page with many tables (app. 200) and macros (Info, Success, Error, Warning, Box and some Display macros, or use the .xar file attached)
- Edit the page using in-place WYSIWYG mode
- Edit a cell from a table by writing some text (e.g. This is a test)
- Observe the responsiveness (initial time for loading the edit mode, how fast the typed text is displayed)
- Enable back the Realtime feature
- Edit the same page with 1 user, then with 2 users using in-place edit mode
- Edit a cell from a table by writing some text (e.g. This is a test)
- Observe the responsiveness of the page and how fast the text is being displayed for both users
Expected results
The time to load the page in edit mode is short. The page is responsive and the text is displayed as it's been typed.
Actual results
The time taken to load the page to edit mode until the user can type is long (app. 8 seconds in average).
The typed text is displayed with quite a long delay.
After having the Realtime feature enabled, the time taken to load the page to edit mode until the user can type is greatly increased.
The typed text has a much longer delay to be displayed (in fact I could not type This is a test because the browser interpreted the typed characters as key shortcuts, see the attached videos).
When the page is edited with 2 or more users, the times are further increased.
The issue was reproduced by Lucian Chevereseanu on another user's instance.