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>
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
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.
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.
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.
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.
(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.
(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.
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.
The commit 1c3a784d38fc5986c78bab8d283c4661347baf43 caused another regression at bug 106133.