I've updated Collabora to 6.2.9, and loolwsd 4.2.2. Then there was a problem with co-editing on Calc. Error are clientzoom nodocloaded. A docloadtimeout error occurred while parsing the load command on the server. Apparently, the problem occurs when everyone is set to Japanese as the display language. If someone changes the display to something other than Japanese, the problem goes away. When this happens, it is rare that user can enter a character. The user typed "1212" in 1-byte, but the cell changed to a different character like "m33n333". This problem is only happening in Calc. I've seen this happen with Nextcloud and Mattermost.
Error Dialog: A nodocloaded error occurred while parsing the clientzoom command on the server. On a Mac, I get a different error. What's more, it's a standalone edit. It's not co-editing. Error dialog: A nodocloaded error occurred while parsing the key command on the server. In case of Mac, users can see "USER-NAME left" around the floppy icon. This problem occurs when the display language is Japanese, and it becomes normal when it is set to something other than Japanese.
Created attachment 159544 [details] Command Error Errors that used to happen on Mac are now happening on Windows, and even when editing alone. There seem to be several patterns in the location of the "clientzoom" in this error dialog. All I know now is "key" and "mouse". When this error occurs I take nearly a minute to restart loolwsd.
The language setting is not a web browsers setting, but a language setting in a web application (Nextcloud, Mattermost).
I've updated to the version below and it hasn't improved. > collaboraofficebasis6.2-calc.x86_64 6.2.10.11-11
I was updated to 6.2.12 and loolwsd 4.6.3. I updated and the problem didn't improve. 1. The user creates and opens a new spreadsheet document. 2. In addition, the user must set English input (1 byte characters) mode in advance. 3. Open a new spreadsheet file and edit it. In this case, there seems to be no problem even in the Japanese display environment. However, if the user then activates the Japanese character (CJK / 2 byte character) input mode and tries to input characters or clicks the mouse, the problem occurs. If an existing file is opened for editing, the same error will occur if the user opens the file in English input mode. In other words, it is impossible to edit existing files in the Japanese display environment.
Will LibreOffice Online be abandoned for the Japanese environment in the future?
Created attachment 162197 [details] verify on demo site I verified this on a demo site provided by Collabora. It behaves slightly differently than my CODE behavior, but it has a similar problem. The demo site is set to display in Japanese with Japanese locale. On the demo site I attempted to type in a series of vertical columns of Japanese. Then, the second time I enter Japanese, it goes into a light freeze and all the letters disappear. There is also a square box in the center that looks like a dialog for a moment.
I have updated to 6.2-17. This version allows me to edit files in Japanese view mode. The remaining problem I'm aware of at this point is using it on my phone. Open Calc/Writer on smart phone and go into edit mode. The user then waits for a long period of time without any operation. Then I get the same error as before. (Attached image "Command Error") It's not as fatal a flaw as it used to be, as users can press the OK button to return to normal.
(In reply to Babbles from comment #8) > I have updated to 6.2-17. This version allows me to edit files in Japanese > view mode. Thanks for the feedback! I was confused about the original description, but the following actually describes a crash: (In reply to Babbles from comment #7) > On the demo site I attempted to type in a series of vertical columns of > Japanese. Then, the second time I enter Japanese, it goes into a light > freeze and all the letters disappear. There is also a square box in the > center that looks like a dialog for a moment. The crash was a regression that started with the following commit: https://cgit.freedesktop.org/libreoffice/core/commit/?id=6e5cf6d3aafaede128dd762be273729a271462f8 This bug report can be closed once the following fix is pushed in master: https://gerrit.libreoffice.org/c/core/+/96693 > The remaining problem I'm aware of at this point is using it on my phone. > Open Calc/Writer on smart phone and go into edit mode. The user then waits > for a long period of time without any operation. Then I get the same error > as before. (Attached image "Command Error") > It's not as fatal a flaw as it used to be, as users can press the OK button > to return to normal. Please open a new bug report on this one, and attach a screenshot on your phone showing this message.
(In reply to Aron Budea from comment #9) I've tried several patterns. This may have also been resolved with today's loolwsd update. The user enters edit mode and waits for 15 minutes. Then a dialog appeared indicating "Pause" today. Thanks,
Created attachment 162296 [details] Error (In reply to Aron Budea from comment #9) An error dialog appears. I had Collabora open in my web browser and in the background. I left my browser unattended for about 30 minutes and then when I activated it I got an error. > A nodecloaded error occurred while parsing the clientzoom command on the server.
The 'nodocloaded' error should be fixed by this commit https://git.libreoffice.org/online/+/9c6739eee01952708409717c5cdf28c8f9fb94a5%5E%21. The error is triggered, probably, by a reconnection and by parallel processing of clientzoom message before loading of the document is finished.
Andras Timar committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/082a6eb7f26f684020e8e086fd4c2fea28c49b3a tdf#132082 Fix a crash in LOKit (Japanese-only) It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
This can be closed now, thanks Andras and Gabriel!