Bug 56937 - EDITING: freeze when drag-and-drop from Calc input line to anywhere on OSX when BetterTouchTool option "window snapping" is active
Summary: EDITING: freeze when drag-and-drop from Calc input line to anywhere on OSX wh...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.6.2.1 rc
Hardware: x86-64 (AMD64) Mac OS X (All)
: medium critical
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: BSA target:4.1.0 target:3.6.5 target:...
Keywords: regression
: 55671 57071 57245 58330 59490 (view as bug list)
Depends on:
Blocks: a11y-macOS
  Show dependency treegraph
 
Reported: 2012-11-09 22:13 UTC by cedric houvenagel
Modified: 2013-01-18 10:34 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
it is what I call "top input field". (17.25 KB, image/png)
2012-11-09 22:13 UTC, cedric houvenagel
Details
top text input during the freeze (11.94 KB, image/png)
2012-11-17 23:14 UTC, cedric houvenagel
Details
sampling of LibreOffice process during the freeze (39.84 KB, text/plain)
2012-11-17 23:14 UTC, cedric houvenagel
Details
Mac OS X 10.6.8 log file for force quit of LibO 3.6.4.1 due to freeze (146.63 KB, text/plain)
2012-11-28 17:59 UTC, Roman Eisele
Details
patch - needs compile testing (please) :-) (6.89 KB, patch)
2012-12-18 13:30 UTC, Michael Meeks
Details

Note You need to log in before you can comment on or make changes to this bug.
Description cedric houvenagel 2012-11-09 22:13:09 UTC
Created attachment 69841 [details]
it is what I call "top input field".

Problem description: 
when starting a "drag and drop" into the "top input field" (the input field common to every cells, just below top menu), libreoffice freezes and you got to kill it. Of course, you loose your current work if not saved.

Steps to reproduce:

1. clic on the "top input field", stay in "on press" state. (in other word, start a "drag and drop")
2. release the button anywhere

Current behavior:
the spinning pinwheel appears. libreoffice freezes. 

Expected behavior:
no spinning pinwheel.

Platform : Mac OS X 10.6.8 
java version "1.6.0_37"
Comment 1 Markus Mohrhard 2012-11-10 17:54:41 UTC
Can you please add some more details how to reproduce it. I'm unable to do produce a crash or a freeze in a current master build.
Comment 2 cedric houvenagel 2012-11-17 23:14:01 UTC
Created attachment 70203 [details]
top text input during the freeze
Comment 3 cedric houvenagel 2012-11-17 23:14:59 UTC
Created attachment 70204 [details]
sampling of LibreOffice process during the freeze
Comment 4 cedric houvenagel 2012-11-17 23:27:42 UTC
hello,
thanks for trying.

I tried again few days ago and I could not reproduce it.
I've just tried again a few minutes ago, and it happens again ! :(
seems to be quite erratic.
FYI, I have a harddrive with 2 bad blocks ... maybe it is the cause ?

How to reproduce it ?
I run LibreOffice, open a new spreadsheet, do the drag and drop from the "top text input".

I add 2 other attachments :
- screenshot of the top input field during the freeze
- "sampling" of the process LibreOffice during the freeze.
Comment 5 Roman Eisele 2012-11-18 15:31:51 UTC
Thank you very much for your bug report --

and especially for the “sampling” of the LibreOffice process during the freeze,
because it gives us an important hint about the nature of this freeze!

The “sampling”/stack trace contains many references to accessibility stuff: ScAccessibleTableBase, hitTestRunner, accessibility etc. This means that the freeze is related to the use of the Mac OS Accessibility API. We have some long-standing bugs in LibreOffice accessibility stuff which were inherited from OpenOffice and which become visible only when the Mac OS Accessibility API is used (see the comments in bug 55571 etc.) ... and it seems that your report is just about another one of these nasty issues.


Therefore, to confirm this observation and to find out what exactly triggers
the bug, please check and answer the following questions:

1) Do you have any accesibility features enabled? Apple’s accessibility
features like “VoiceOver” or “Enable access for assistive devices”, which get
enabled in “System Preferences > Universal Access” (in French:
“Préférences Système > Accès universel”), are known to cause many crashes and freezes in LibreOffice. So please try to disable any accesibility features, then check if the problem is still reproducible.

2) Do you have installed any window management/user interface utilities/apps/control panels/extensions for Mac OS X like 
   * AquaSnap                * BetterSnapTool
   * BetterTouchTool         * Breeze
   * Cinch                   * Divvy
   * DoublePane              * Flexiglass
   * HyperDock               * iSnap
   * Moom                    * RightZoom
   * ShiftIt                 * SizeUp
   * SizeWell                * Spectacle
   * Stay                    * TileWindows
   * WindowTidy            ... or something similar?

And/or do you use any mouse cursor/pointer utility, i.e. some little application or control panel etc. which animates or replaces etc. the mouse curser/pointer, like
   * LazyMouse?

And/or do you use any special software which could be related to accessibility stuff, e.g. a screen reader, screen magnifier, speech recognition software,
a text-to-speech (dictation) application, or similar?

All these and many similar utilities rely heavily on Mac OS accessibility features and therefore can cause LibreOffice to crash or freeze. So please check if you have installed any utility of this kind and try to disable it
(or to add LibreOffice to the list of excluded applications for the utility,
if there is such a thing).


So please check these possibilities, if any of them helps to make the freeze go away, and report the results here.

Thank you very much!
Comment 6 cedric houvenagel 2012-11-21 07:50:17 UTC
Hello

thanks for your well documented answer.
You're right, I have BetterTouchTool installed (version 0.91).

I tried to disable/enable features to narrow the bug down and I was successful. :)

When I disable the BetterTouchTool functionality named "Enable window snapping", LibreOffice doesn't freeze.
While I'm doing this, "System Preferences > Universal Access > Enable access for assistive devices" is still enabled (as it is required by BetterTouchTool)

I'm really glad I could help you and the LibreOffice team.
You're doing a fantastic job … keep on going :)
Comment 7 Roman Eisele 2012-11-28 11:05:54 UTC
Hello Cédric,

(In reply to comment #6)
> You're right, I have BetterTouchTool installed (version 0.91).
> 
> I tried to disable/enable features to narrow the bug down and I was
> successful. :)
> 
> When I disable the BetterTouchTool functionality named "Enable window
> snapping", LibreOffice doesn't freeze.
> While I'm doing this, "System Preferences > Universal Access > Enable access
> for assistive devices" is still enabled (as it is required by
> BetterTouchTool)

thank you very much for your answer, and for the sampling file!
Both are very helpful. I am sorry for the long delay -- I had to fight with many other bugs and was ill. Now I will finally try to reproduce this issue ...
Comment 8 Roman Eisele 2012-11-28 17:57:53 UTC
First, I checked the official terminology; as LibreOffice help tells us, the “top input field” is officially called “Input Line” ;-) So let’s change the Summary accordingly, and also add the hint that this bug is triggered by the BetterTouchTool option “window snapping”.

Second, with BetterTouchTool installed and the option “Enable window snapping” checked (thank you for discovering that this option is the necessary thing!),
the freeze is easily

REPRODUCIBLE both with
* LibreOffice 3.4.6.1 (Build ID: a9a0717)
* LOdev 4.0.0.0.alpha1+ (Build ID: 6aabe09ac092c51d4b394bde9c7ea0055b952e3;
  pull time: 2012-11-26 00:28:52)
on Mac OS X 10.6.8 (Intel). Setting Status to NEW (= confirmed).
Comment 9 Roman Eisele 2012-11-28 17:59:41 UTC
Created attachment 70739 [details]
Mac OS X 10.6.8 log file for force quit of LibO 3.6.4.1 due to freeze



This is the log file created by Mac OS X for the freeze;
the stack backtrace is very similar to the one in Cédric’s log file.
Comment 10 Roman Eisele 2012-11-28 18:08:12 UTC
But this bug is NOT reproducible in LibreOffice 3.5.7.
So it is a regression.

When has this regression been introduced? After testing various 3.6/3.7 daily builds, we got it:

The bug is NOT reproducible with
  LOdev 3.6.2.0+ (Build ID: cfbfa26; pull time: 2012-09-07 10.35.10)
But it is FIRST reproducible with
  LOdev 3.6.2.0+ (Build ID: c303961; pull time: 2012-09-11 08.49.57)
i.e. the bug was introduced by some patch committed to the 3.6 branch between 2012-09-07 10.35.10 and 2012-09-11 08.49.57.

But the most important changes in that short time frame where the two fixes for bug 47368, which fixed many other problems related to Mac OS X accessibility.
So I fear that -- horribile dictu -- this present bug is a negative side-effect of one of our two important patches which fixed bug 47368:

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3234b715b5a6d13ee673b41066eb565706be5ec9

or

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9b9d45e35103e6884e0a87c35c07c74899f40614

just like bug 55671 and bug 57245, which seems to have been introduced by one of these patches, too ...
Comment 11 Michael Meeks 2012-12-18 12:54:39 UTC
Well - it is deeply frustrating not to be able to debug this - but assumigng the app just hangs - then one of the loops on the stack frames from here are simply not making progress (somehow):

                                                            9 -[AquaA11yWrapper accessibilityHitTest:] + 374 (in libvcllo.dylib) [0x1b1cf36]
                                                              9 hitTestRunner(com::sun::star::awt::Point, com::sun::star::uno::Reference<com::sun::star::accessibility::XAccessibleContext>) + 683 (in libvcllo.dylib) [0x1b1caeb]
                                                                9 hitTestRunner(com::sun::star::awt::Point, com::sun::star::uno::Reference<com::sun::star::accessibility::XAccessibleContext>) + 683 (in libvcllo.dylib) [0x1b1caeb]
                                                                  9 hitTestRunner(com::sun::star::awt::Point, com::sun::star::uno::Reference<com::sun::star::accessibility::XAccessibleContext>) + 683 (in libvcllo.dylib) [0x1b1caeb]
                                                                    9 hitTestRunner(com::sun::star::awt::Point, com::sun::star::uno::Reference<com::sun::star::accessibility::XAccessibleContext>) + 683 (in libvcllo.dylib) [0x1b1caeb]
                                                                      9 hitTestRunner(com::sun::star::awt::Point, com::sun::star::uno::Reference<com::sun::star::accessibility::XAccessibleContext>) + 683 (in libvcllo.dylib) [0x1b1caeb]
                                                                        9 hitTestRunner(com::sun::star::awt::Point, com::sun::star::uno::Reference<com::sun::star::accessibility::XAccessibleContext>) + 433 (in libvcllo.dylib) [0x1b1c9f1]
                                                                          9 ScAccessibleTableBase::getAccessibleChild(long) + 131 (in libsclo.dylib) [0x20dc57d3]
                                                                            9 ScAccessibleSpreadsheet::getAccessibleCellAt(long, long) + 133 (in libsclo.dylib) [0x20dc1df5]
                                                                              9 ScAccessibleSpreadsheet::GetAccessibleCellAt(long, long) + 179 (in libsclo.dylib) [0x20dbfaa3]
                                                                                9 ScAccessibleCell::ScAccessibleCell(com::sun::star::uno::Reference<com::sun::star::accessibility::XAccessible> const&, ScTabViewShell*, ScAddress&, long, ScSplitPos, ScAccessibleDocument*) + 160 (in libsclo.dylib) [0x20d7dcf0]
                                                                                  8 accessibility::AccessibleStaticTextBase::AccessibleStaticTextBase(std::auto_ptr<SvxEditSource>) + 72 (in libeditenglo.dylib) [0x219a2e78]
                                                                                    8 accessibility::AccessibleStaticTextBase_Impl::AccessibleStaticTextBase_Impl() + 61 (in libeditenglo.dylib) [0x219a2d6d]
                                                                                      8 accessibility::AccessibleEditableTextPara::AccessibleEditableTextPara(com::sun::star::uno::Reference<com::sun::star::accessibility::XAccessible> const&, accessibility::AccessibleParaManager const*) + 732 (in libeditenglo.dylib) [0x21993f7c]
                                                                                        8 comphelper::AccessibleEventNotifier::registerClient() + 52 (in libcomphelpgcc3.dylib) [0x150e04]
                                                                                          6 comphelper::AccessibleEventNotifier::generateId() + 90 (in libcomphelpgcc3.dylib) [0x1509fa]
                                                                                            6 std::_Rb_tree_increment(std::_Rb_tree_node_base const*) + 16 (in libstdc++.6.dylib) [0x96f63643]
                                                                                          1 comphelper::AccessibleEventNotifier::generateId() + 101 (in libcomphelpgcc3.dylib) [0x150a05]
                                                                                          1 comphelper::AccessibleEventNotifier::generateId() + 99 (in libcomphelpgcc3.dylib) [0x150a03]
                                                                                  1 accessibility::AccessibleStaticTextBase::AccessibleStaticTextBase(std::auto_ptr<SvxEditSource>) + 118 (in libeditenglo.dylib) [0x219a2ea6]
                                                                                    1 accessibility::AccessibleStaticTextBase::SetEditSource(std::auto_ptr<SvxEditSource>) + 42 (in libeditenglo.dylib) [0x219a2b1a]
                                                                                      1 accessibility::AccessibleStaticTextBase_Impl::SetEditSource(std::auto_ptr<SvxEditSource>) + 77 (in libeditenglo.dylib) [0x219a2acd]
                                                                                        1 accessibility::AccessibleEditableTextPara::SetEditSource(SvxEditSourceAdapter*) + 195 (in libeditenglo.dylib) [0x2198abb3]
                                                                                          1 accessibility::AccessibleEditableTextPara::TextChanged() + 36 (in libeditenglo.dylib) [0x21989ec4]
                                                                                            1 comphelper::OCommonAccessibleText::getText() + 25 (in libcomphelpgcc3.dylib) [0x154ba9]
                                                                                              1 accessibility::AccessibleEditableTextPara::implGetText() + 22 (in libeditenglo.dylib) [0x219909b6]
                                                                                                1 accessibility::AccessibleEditableTextPara::GetTextLen() const + 23 (in libeditenglo.dylib) [0x21990177]
                                                                                                  1 accessibility::AccessibleEditableTextPara::GetTextForwarder() const + 40 (in libeditenglo.dylib) [0x2198e2f8]
                                                                                                    1 SvxEditSourceAdapter::GetTextForwarderAdapter() + 44 (in libeditenglo.dylib) [0x21a9ddbc]
                                                                                                      1 ScAccessibleCellTextData::GetTextForwarder() + 1105 (in libsclo.dylib) [0x20dc94e1]
                                                                                                        1 EditEngine::CalcTextWidth() + 80 (in libeditenglo.dylib) [0x219b5dd0]
                                                                                                          1 ImpEditEngine::CalcTextWidth(unsigned char) + 538 (in libeditenglo.dylib) [0x219e20aa]
                                                                                                            1 OutputDevice::Push(unsigned short) + 1 (in libvcllo.dylib) [0x193fbc1]
Comment 12 Michael Meeks 2012-12-18 12:59:27 UTC
Wow - so it seems the spreadsheet a11y code is really broken and for some reason we only see it now:

uno::Reference< XAccessible > SAL_CALL
    ScAccessibleTableBase::getAccessibleChild(sal_Int32 nIndex)
        throw (uno::RuntimeException,
        lang::IndexOutOfBoundsException)
{
    SolarMutexGuard aGuard;
    IsObjectValid();

    if (nIndex >= getAccessibleChildCount() || nIndex < 0)
        throw lang::IndexOutOfBoundsException();

    sal_Int32 nRow(0);
    sal_Int32 nColumn(0);
    sal_Int32 nTemp(maRange.aEnd.Col() - maRange.aStart.Col() + 1);
    nRow = nIndex / nTemp;
    nColumn = nIndex % nTemp;
    return getAccessibleCellAt(nRow, nColumn);
}

It rather looks like we're iterating over all the cells in a spreadsheet in some horrible way - creating new a11y peers for them - just in order to see if we have a hit test :-)

That looks really dumb to me ;-) apparently no cropping only for cells that are visible even is present ;-)
Comment 13 Michael Meeks 2012-12-18 13:02:23 UTC
ScAccessibleSpreadsheet::ScAccessibleSpreadsheet(
        ScAccessibleDocument* pAccDoc,
        ScTabViewShell* pViewShell,
        SCTAB nTab,
        ScSplitPos eSplitPos)
    :
    ScAccessibleTableBase (pAccDoc, GetDocument(pViewShell),
        ScRange(ScAddress(0, 0, nTab),ScAddress(MAXCOL, MAXROW, nTab))),

so - this loop could never complete - even if it could do all 10^6 * 10^4 cells.

Wow - what a monster.

Fundamentally this comes down to a -really- poor set of standards body decisions that try to improve and increase a11y by exposing near infinite sets of data to an accessibility-technology ignorant of the risks, and through a totally inadequate API.

Having said that - we screw this up really badly for hit testing - and apparently always have.
Comment 14 Michael Meeks 2012-12-18 13:29:49 UTC
Got it - however, I really need someone to test my patch: a plain compile test on Mac would be appreciated, I'm pretty confident in the logic - I'll attach that.
Comment 15 Michael Meeks 2012-12-18 13:30:17 UTC
Created attachment 71725 [details]
patch - needs compile testing (please) :-)
Comment 16 Michael Meeks 2012-12-18 13:31:39 UTC
*** Bug 55671 has been marked as a duplicate of this bug. ***
Comment 17 Michael Meeks 2012-12-18 13:32:10 UTC
*** Bug 57245 has been marked as a duplicate of this bug. ***
Comment 18 steve -_- 2012-12-18 13:36:43 UTC
Michael, if you link some executable code, I'd be happy to do some testing on OS X 10.8.2. Please include a detailed step-by-step on what you want to be tested.

is status still new or is this assigned to you now?
Comment 19 Michael Meeks 2012-12-18 13:42:52 UTC
we tend not to assign bugs ;-) but yes - I'm taking an interest - IMHO the bug is fixed; as/when someone compile tests it I'll push to master and -4-0 and then a build will pop out of a tinderbox eventually. I don't actually have a mac myself :-)
Comment 20 Don't use this account, use tml@iki.fi 2012-12-18 15:09:44 UTC
git am'ing and test compiling... will push if compiles fine
Comment 21 Don't use this account, use tml@iki.fi 2012-12-18 16:05:17 UTC
I reproduced the bug, then applied Michael's patch and verified that it helps, yes! Pushed to master.
Comment 22 Not Assigned 2012-12-18 16:10:35 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=15aac31ebac23ef745400a8d9c146aef85923c9d

fdo#56937 - mac a11y hang related to traversing vast, broken hierarchies.



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 23 Not Assigned 2012-12-18 16:53:13 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

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

fdo#56937 - mac a11y hang related to traversing vast, broken hierarchies.


It will be available in LibreOffice 3.6.5.

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 24 Not Assigned 2012-12-18 16:53:35 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a4a467c6e742ea40986287c5f546b0daec295289&g=libreoffice-4-0

fdo#56937 - mac a11y hang related to traversing vast, broken hierarchies.


It will be available in LibreOffice 4.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 25 Roman Eisele 2012-12-20 09:23:05 UTC
*** Bug 58330 has been marked as a duplicate of this bug. ***
Comment 26 Roman Eisele 2012-12-23 17:04:21 UTC
VERIFIED as FIXED:

while I can still easily reproduce this bug on Mac OS X 10.6.8 (Intel), when the BetterTouchTool option "window snapping" is active, with our 1st beta:
  Version 4.0.0.0.beta1 (Build ID: 87906242e87d3ddb2ba9827818f2d1416d80cc7)
  TinderBox: MacOSX TDF Release, Branch:libreoffice-4-0,
  Time: 2012-12-05_22:13:37
and also e.g. in this master build:
  Version 4.1.0.0.alpha0+ (Build ID: e43d62fb39e0b6b3e59b22110460d23b6d507b5)
  TinderBox: MacOSX-Intel@1-built_no-moz_on_10.6.8, Branch:master,
  Time: 2012-12-06_09:19:57

I can no longer reproduce this bug beginning with the 1st available master build after the patch for this bug has been committed (see comment #22 above):
  Version 4.1.0.0.alpha0+ (Build ID: 413d1a932eb4c47510dd05905c1ff467cb186d0)
  TinderBox: MacOSX-Intel@1-built_no-moz_on_10.6.8, Branch:master,
  Time: 2012-12-19_04:13:37

So this bug is really fixed, and so are its duplicates.


@ Michael Meeks:
Thank you very much for fixing this nasty issue! This is a big improvement for LibreOffice on Mac OS X, it will help many users, and it will also make easier the life for us QA volunteers (fewer bug reports ;-).

Also thanks to Tor Lillqvist for his co-operation!
Comment 27 Roman Eisele 2012-12-23 18:23:19 UTC
*** Bug 57071 has been marked as a duplicate of this bug. ***
Comment 28 Roman Eisele 2012-12-23 18:29:30 UTC
Very interesting:

Bug 57071 (“UI: Freeze when resizing tabs/horizontal scrollbar on OSX with BetterTouchTool or RightZoom running”) is much older than the present one -- bug 57071 is reproducible since LibreOffice 3.3.0, while the present issue first appeared in 3.6.2.1 --, but nevertheless the patch for the present issue seems to have healed bug 57071, too.

Why? Probably the roots of the present bug are much older than 3.6.2.1 (which is no surprise, of course!), and it was just “hidden” by another bug (namely bug 47368) until 3.6.2.1.
Comment 29 cedric houvenagel 2012-12-28 20:04:56 UTC
FYI, I couldn't reproduce the bug with this build :

Version 4.1.0.0.alpha0+ (Build ID: 699132c269a6c6d9e815fc582e2e6a106e46923)
TinderBox: MacOSX-Intel@1-built_no-moz_on_10.6.8, Branch:master, Time: 2012-12-27_01:05:51

Thanks all for your great work with special mention to Roman and Michael, who surrounded and defeated the a11y hittest monster ;)

happy New Year !!
Comment 30 Michael Meeks 2013-01-18 10:34:55 UTC
*** Bug 59490 has been marked as a duplicate of this bug. ***