Bug 100903 - Calc hangs when preediting Japanese with Mozc + GTK plugin
Summary: Calc hangs when preediting Japanese with Mozc + GTK plugin
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.2.0.1 rc
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Takeshi Abe
QA Contact:
URL:
Whiteboard: target:5.3.0 target:5.2.1 target:5.2.0
Keywords: bibisectRequest, regression
Depends on:
Blocks:
 
Reported: 2016-07-14 02:08 UTC by Takeshi Abe
Modified: 2017-03-01 12:45 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Takeshi Abe 2016-07-14 02:08:09 UTC
Environment
-----------
Debian jessie x86_64
GNOME 3.14 (1:3.14+3)
libgtk 3.14 (3.14.5-1+deb8u1)
ibus 1.5.9-1
ibus-gtk 1.5.9-1
ibus-gtk3 1.5.9-1
ibus-mozc 1.15.1857.102-1+b1

STR
---
0. Install the deb packages of LibO 5.2.0.2 distributed at
   <http://dev-builds.libreoffice.org/pre-releases/deb/x86_64/>
1. Start Calc with GTK plugin:
   $ SAL_USE_VCLPLUGIN=gtk /opt/libreoffice5.2/program/scalc
2. Make sure that the focus is on cell A1.
3. Switch input mode from 'Direct input' to 'Hiragana'
4. Typing "ab" (will display a IM subwindow with preeditted "あ")
Then LibO no longer responds to further input.
Warning: the whole system will hang soon unless you kill the soffice process.

Note
----
No problem when starting LibO with SAL_USE_VCLPLUGIN=gen.
Moreover, this issue does not occur when using ibus-anthy instead of ibus-mozc.
Originally reported at ja-discuss mailing list:
<http://listarchives.libreoffice.org/ja/discuss/msg04134.html>
Comment 1 Shinji Enoki 2016-07-14 15:52:23 UTC
I confirm in the following versions.

OS: Debian jessie 64bit
GNOME 3.14
fcitx + Mozc

Version:5.2.0.2
Build ID: a7567a46e5d2953c320b13eb88a3981c4f9bd1e0
CPU Threads: 4; OS Version: Linux 3.16; UI Render: default; 
Locale: ja-JP (ja_JP.utf8)

Reproduce steps.
1. Start Calc
2. Click cell "A1"
3. Type character
LibreOffice freeze

Do not freeze case:
1. Start Calc
2. Click "Input line"
3. Type characters
Comment 2 Takeshi Abe 2016-07-18 20:55:17 UTC
Changed the title as this is not ibus-specific.
Also, marked as a regression since LibO 5.1.4 does not suffer from this problem.
Comment 3 Commit Notification 2016-07-20 08:20:01 UTC
Takeshi Abe committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=1c81af2c1814e8bd12701f85e09cebf5fe206647

Resolves: tdf#100903 Calc hangs when preediting Japanese with GTK plugin

It will be available in 5.3.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 4 Commit Notification 2016-07-20 10:12:08 UTC
Takeshi Abe committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3af2382e6155abbb3e9e6102878bad1fa3f79373&h=libreoffice-5-2

Resolves: tdf#100903 Calc hangs when preediting Japanese with GTK plugin

It will be available in 5.2.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 5 Commit Notification 2016-07-22 12:14:28 UTC
Takeshi Abe committed a patch related to this issue.
It has been pushed to "libreoffice-5-2-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b39b835e1728a8871f017f1af3b3b642fdbff1d8&h=libreoffice-5-2-0

Resolves: tdf#100903 Calc hangs when preediting Japanese with GTK plugin

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 6 Justin L 2017-01-13 05:36:46 UTC
(In reply to Takeshi Abe from comment #2)
> Changed the title as this is not ibus-specific.
> Also, marked as a regression since LibO 5.1.4 does not suffer from this
> problem.

A bisect to identify the cause of the regression would be nice to document here, since comment 3's fix does not appear to be directly tied to whatever caused the regression.

The fix for this bug has caused serious regressions, but without better documentation I can't do anything to ensure both problems are fixed.
Comment 7 Takeshi Abe 2017-01-13 07:02:12 UTC
(In reply to Justin L from comment #6)
> The fix for this bug has caused serious regressions, but without better
> documentation I can't do anything to ensure both problems are fixed.
The background of this issue was that, when Mozc asks Calc to retrieve
surrounding text, the gtk plugin used to sweep all possible cells (~2^30)
as children of the IM context to find focus.
I found the behavior is due to poor accessibility implementation as Michael
Meeks explained a similar situation on OS X in his comments at tdf#56937.
Comment 8 Justin L 2017-02-17 18:27:37 UTC
linux-daily-bibisect-53 indicates the freezing likely started with
author	Justin Luth <justin_luth@sil.org>	2016-02-10 10:12:35 (GMT)
commit	598e6a024163f1510d076000788b7745625f5ed5
tdf#96685 - ensure FindFocus a11y context is valid EditableText
signalIMDelete and Retrieve Surrounding Text search for the accessible
context that has the focus.  When a context with the FOCUSED state was
found it was automatically returned, assuming that the reference was valid.

In Draw tables, especially when using the arrow keys to move between
cells, that often was not true.  So, instead of returning a broken
reference, keep searching through the children until a valid
AccessibleEditableText item that is marked as FOCUSED is found.
Comment 9 Kevin Suo 2017-03-01 06:58:12 UTC
The commit 1c3a784d38fc5986c78bab8d283c4661347baf43 caused another regression at bug 106133.