Download it now!
Bug 132082 - Crash when entering text in multiple cells in Japanese language environment (LOOL)
Summary: Crash when entering text in multiple cells in Japanese language environment (...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice Online
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.1.0
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2020-04-13 10:49 UTC by Babbles
Modified: 2020-07-26 02:01 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Command Error (49.17 KB, image/png)
2020-04-14 01:03 UTC, Babbles
Details
verify on demo site (6.80 MB, video/quicktime)
2020-06-19 05:51 UTC, Babbles
Details
Error (55.54 KB, image/png)
2020-06-22 07:51 UTC, Babbles
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Babbles 2020-04-13 10:49:57 UTC
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.
Comment 1 Babbles 2020-04-13 15:01:46 UTC
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.
Comment 2 Babbles 2020-04-14 01:03:43 UTC
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.
Comment 3 Babbles 2020-04-29 17:14:22 UTC
The language setting is not a web browsers setting, but a language setting in a web application (Nextcloud, Mattermost).
Comment 4 Babbles 2020-05-08 01:29:57 UTC
I've updated to the version below and it hasn't improved.
> collaboraofficebasis6.2-calc.x86_64 6.2.10.11-11
Comment 5 Babbles 2020-05-14 16:51:31 UTC
 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.
Comment 6 Babbles 2020-06-08 09:31:37 UTC
Will LibreOffice Online be abandoned for the Japanese environment in the future?
Comment 7 Babbles 2020-06-19 05:51:12 UTC
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.
Comment 8 Babbles 2020-06-21 04:00:13 UTC
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.
Comment 9 Aron Budea 2020-06-22 03:09:33 UTC
(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.
Comment 10 Babbles 2020-06-22 06:58:14 UTC
(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,
Comment 11 Babbles 2020-06-22 07:51:54 UTC
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.
Comment 12 Gabriel Masei 2020-07-23 05:12:05 UTC
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.
Comment 13 Commit Notification 2020-07-23 11:47:07 UTC
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.
Comment 14 Aron Budea 2020-07-26 02:01:54 UTC
This can be closed now, thanks Andras and Gabriel!