Bug 55156 - Hang on accessing any pane in the application Options dialog, when Cinch is running (related to Mac OS accessibility)
Summary: Hang on accessing any pane in the application Options dialog, when Cinch is r...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.3.0 release
Hardware: x86-64 (AMD64) Mac OS X (All)
: medium major
Assignee: Don't use this account, use tml@iki.fi
URL:
Whiteboard: target:3.7.0 target:3.6.3
Keywords:
: 55399 (view as bug list)
Depends on:
Blocks: a11y-macOS
  Show dependency treegraph
 
Reported: 2012-09-20 16:42 UTC by Roman Eisele
Modified: 2012-10-03 11:17 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Log file created by MacOS X when I had to force quit LibreOffice 3.6.2.1 because of the hang (145.39 KB, text/plain)
2012-09-20 16:45 UTC, Roman Eisele
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Eisele 2012-09-20 16:42:03 UTC
When Cinch, a popular window management utility for Mac OS X, is installed and running, any attempt to access any pane of the application Options dialog leads to a hang. (See “steps to reproduce” below for details!)

This is very probably yet another bug in the LibreOffice code related to Mac OS X accessibility features, because
 * Cinch relies heavily on these accessibility features (it requires the system
   preference “Universal Access > Enable access for assistive devices”
   to be checked), and
 * the log file created by Mac OS X when I forced quit LibreOffice because of
   the hang contains many references to accessibility stuff.

NB: I create a new bug report for this issue, because no one of the existing bug reports about problems accessing panes of the application Options dialog covers this special issue clearly.


Steps to reproduce:
-------------------
1) Download Cinch, available from
       http://www.irradiatedsoftware.com/cinch/index.html
   (ShareWare, but you can try it for free, just as I did).
2) Start it just like a normal application.
   -> During startup, Cinch will automatically enable
   the system preference “Enable access for assistive devices”
   (in “System Preferences > Universal Access”) for you.
3) Optional: Rename your LibreOffice user profile folder,
   to preclude any influence of local settings on the test results.
4) Start LibreOffice.
   -> The Start Center window appears.
5) Select “LibreOffice > Preferences...” from the menu bar.
   -> the dialog window “Options” appears,
   it shows by default the first pane: “LibreOffice > User data”.
6) Now try to select any other pane from the list at the left,
   e.g. “General”.
   -> First, nothing happens;
   then the spinning cursor appears,
   LibreOffice hangs.
   [In the case that you *can* select another pane (I have seen this once),
   just try to repeat this, i.e. select yet another pane;
   now LibreOffice hangs.]

Attached to this bug report you will find the log file created by Mac OS X when I forced quit LibreOffice because of this hang.


Reproducible with:
..................
* LibreOffice 3.3.0 (OOO330m19, Build:6, tag libreoffice-3.3.0.4)
* LibreOffice 3.5.6.2 (Build ID: e0fbe70-dcba98b-297ab39-994e618-0f858f0)
* LibreOffice 3.6.2.1 (Build ID: ba822cc)
* LOdev 3.7.0.0.alpha0+, Build ID: 01e6335, Pull time: 2012-09-18 04:23:03
* and probably every other LibreOffice version.

This bug is NOT identical to bug 47368, and NOT fixed by the two (three) patches for it.
Comment 1 Roman Eisele 2012-09-20 16:45:38 UTC
Created attachment 67459 [details]
Log file created by MacOS X when I had to force quit LibreOffice 3.6.2.1 because of the hang
Comment 2 Roman Eisele 2012-09-20 16:47:34 UTC
Status NEW (confirmed) because of
  https://bugs.freedesktop.org/show_bug.cgi?id=49942#c6
which mentions the same problem (also involving Cinch).
Comment 3 Don't use this account, use tml@iki.fi 2012-09-26 12:07:48 UTC
Here the code ends up in an infinite loop in the same place where therr was an infinite loop after the crash fix for bug #47275... But for this case the check for a "self-parented" object that I added to break out of the loop does not work. Hmm.
Comment 4 Not Assigned 2012-09-26 13:08:40 UTC
Tor Lillqvist committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3376f682a77c16f4da63dc14c45d294425e5ba8a

Silly workaround for fdo#55156



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 Don't use this account, use tml@iki.fi 2012-09-26 13:13:50 UTC
The above extremely ugly workaround "fixes" the problem, but is obvioously not something I would be proud of... Cherry-pick appreciated... A real fix even more appreciated, but... how much time do we want to spend on this?
Comment 6 Roman Eisele 2012-09-30 11:50:30 UTC
*** Bug 55399 has been marked as a duplicate of this bug. ***
Comment 7 Not Assigned 2012-10-01 09:46:58 UTC
Tor Lillqvist committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=887f67674108b5f45e7748f6fbbf1fa0131b0ba8&g=libreoffice-3-6

Silly workaround for fdo#55156


It will be available in LibreOffice 3.6.3.

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 8 Roman Eisele 2012-10-01 15:13:03 UTC
Thank you very much, Tor, for all your debugging work applied to this issue, and for your patch, even if you just call it a “silly workaround”!


I have tested the new workaround with a current master build:
LOdev 3.7.0.0.alpha0+ (Build ID: 3f84462b, pull time: 2012-09-30 06:38:06),
on Mac OS X 10.6.8 (Intel), Cinch running as required.

I can confirm a big progress: there is no hang anymore (and no crash, as it was caused by another a11y-related bug); the LibreOffice “Options” dialog window is usable again even when Cinch is running.

Of course, there is still a noticeable delay when changing the options pane.
To see more easily what’s going on, open the Terminal, start “top”, and let it run in the background while playing with LibreOffice. My observations:

* When I open the LibreOffice “Options” dialog, everything is fine (the CPU usage of the soffice process jumps only for a second or not at all).

* As soon as I try to change the current options pane, there is a 1-2 seconds dealy, and the CPU usage of the “soffice” process jumps to ca. 100%. Interesting enough, it stays at that high level even after the new options pane is visible. You can “feel” this also in the LibreOffice UI: changing anything in the new options pane (e.g., typing something into an edit field, or just checking a checkbox) works very slowly. But it works, of course, and this is a big progress.

* If you change the options pane again, the same thing happens: a 1-2 seconds delay, then the new options pane is visible, editing/changing anything is very slow. CPU stays at more or less 100%.

* Even when I close the “Options” dialog window, and there is another LibreOffice window open (Start Center or document window), the “soffice” process first stays at 100% CPU usage; as soon as I click on the Start Center or document window so that it gets the focus, the CPU usage goes down to normal level (< 1%).

* If I close the “Options” dialog window, and there is no other LibreOffice window open, not even the Start Center window (this is possible on Mac OS X, not on Win), the CPU usage immediately goes down to normal level.


@ Tor (and Michael Meeks):

A big progress, and the main bug (the hang) is fixed now. Great!

Of course, it would be even better if we could get the CPU usage (which stays at 100% after the first options pane change) down to a normal level again; this would make it much easier to change anything in the “Options” window, and give us back a good User experience. Do you see any chance to achieve this (without too much additional work, of course)?

Anyway, thank you very much!