as requested by Roman Eisele, here's the new bug: I experience a beachball & crash whenever I right-click the table name in Calc (wanting to rename that) with System Preferences > Accessability Controls > Enable access for assistive devices (active). The crash does not appear when this setting is inactive. I also tested the 3.6.3 nightly of LO and still experience identical behavior. crash log: http://cl.ly/39453g1m3n2P @Roman: put you in CC: & feel free to delete my comments on the meta ticket now that we have this ticket here. Meta ticket is: https://bugs.freedesktop.org/show_bug.cgi?id=55571
Thank you very much for the new bug report! This makes it easier for us to manage that issue. -- First, I just adapt some fields.(In reply to comment #0) > @Roman: put you in CC: & feel free to delete my comments on the meta ticket > now that we have this ticket here. I would like to do so, but AFAIK we can not delete any comments here ;-) (At least nobody does so, and I do not even know how to do it.) But that’s not important, let’s go on here.
Created attachment 68172 [details] Reporter's log file for bug 55671 (Mac OS X 10.8.2, LibO 3.6.2.2) Let us attach the log file right here, and as plain text.
Well, experience has shown that many bugs of this kind do not only involve the system preference “Enable access for assistive devices”, but also that some additional utility is installed and running which uses this setting. Therefore, in order to make reproducing and fixing this issue easier, my usual questions ;-): 1) Do you use any window management utility for Mac OS X, i.e. a little application, app, control panel, or utility which helps to arrange, restore etc. the user interface windows, like * AquaSnap * BetterSnapTool * BetterTouchTool * Breeze * Cinch * Divvy * DoublePane * Flexiglass * HyperDock * iSnap * Moom * RightZoom * ShiftIt * SizeUp * SizeWell * Spectacle * Stay * TileWindows * WindowTidy or something similar? 2) 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? 3) 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? To know this would be very helpful! Thank you very much for your answer!
@Roman: Thanks so much for taking care of this. 1) BetterSnapTool is running on my system and it is indeed the software requiring the "Enable access for assistive devices" setting to be active. 2) No. 3) Dragon Dictate 3 is installed on my system but not often running. Let me know if you need further info.
@ SteveBell: Thank you very much for this important piece of information! Now I *should* be able to reproduce this, trying ...
I have problems to reproduce it with BetterSnapTool (I don’t want to buy it, even if it is cheep, and if I download the trial version from http://boastr.de/BetterSnapToolTrial.zip it just says “This trial version has expired”). But I CAN reproduce and confirm the issue with RightZoom, which is even better because RightZoom is free and our favourite toy for reproducing Mac accessibility issues ;-). I get a hang/freeze, not a crash, and a slightly different stack trace, but nevertheless this very probably the same issue. Good! So REPRODUCIBLE with LibreOffice 3.6.2.2 on Mac OS X 10.6.8 (Intel) and RightZoom running. I will test other LibreOffice versions tomorrow, then we can forward this to the developers.
Created attachment 68350 [details] Mac OS X 10.6.8 log file created on force quit due to hang of LibO 3.6.2.2, with RightZoom running My log file, with the simple stack trace (w/o full symbols, sorry) created by Mac OS X 10.6.8 when I had to force quit LibreOffice 3.6.2.2. NB: when using RightZoom for reproducing this issue, it is not even necessary to check “Enable Access for assistive devices”.
Created attachment 68405 [details] Mac OS X 10.6.8 log file created on force quit due to hang of LOdev 3.7a pull time 2010-10-09, with RightZoom running, Enable access not checked Further testing shows: I can reproduce exactly the same hang/freeze on Mac OS X 10.6.8 (Intel) with RightZoom running to provoke the bug and * Current 3.6 daily: LibreOffice/LOdev 3.6.3.0+ (build ID: a00d5c5; pull time: 2012-10-09 04:00:19 * Current Master build: LOdev 3.7.0.0.alpha0+ (build ID: 1ae1bca; pull time: 2012-10-09 04:37:06) So both actively maintained versions are affected by this bug. Interesting enough, I can NOT reproduce this hang/freeze on the same machine with RightZoom running to provoke the bug and * LibreOffice 3.5.7.1 (Build ID: 3fa2330-e49ffd2-90d118b-705e248-051e21c) * LibreOffice 3.3.0 * LibreOffice 3.4.0 * LibreOffice 3.4.6 * LibreOffice 3.5.0 * LibreOffice 3.6.0.4 (official release) Especially the last item is interesting. I can’t believe it myself, but I have tried quite a few times, and it really seems that this bug was newly introduced. (Is it possible that this bug is an unwanted side-effect of our two fixes for bug 47368?)
OK, we got it. I can NOT reproduce this hang/freeze with [1] LibreOffice/LOdev 3.6.2.0+ daily -- build ID: cfbfa26, build date: 2012-09-07. But I CAN reproduce this hang/freeze with [2] LibreOffice/LOdev 3.6.2.0+ daily -- build ID: cfbfa26, build date: 2012-09-11. Because [1] was the last 3.6 daily build which I have *before* the two patches for bug 47368 where backported to the 3.6 branch, and [2] is the first 3.6 daily build which I have *after* the two patches were applied, it seems reasonable that this bug is a negative side effect of these two patches: http://cgit.freedesktop.org/libreoffice/core/commit/?id=3234b715b5a6d13ee673b41066eb565706be5ec9 or http://cgit.freedesktop.org/libreoffice/core/commit/?id=9b9d45e35103e6884e0a87c35c07c74899f40614 (I would guess, of the latter, because the bug seems related to the code touched by that commit -- but this is just the guess of a simple-minded bug wrangler). This is all what a bug wrangler can do about this issue; now I hope our developers will find a solution, i.e., improving the patches so that the present bug will be removed without re-introducing bug 47368. Not easy ...
@ Michael Meeks, Tor Lillqvist: Hi Michael and Tor, here is a new bug related to Mac OS X accessibility -- it is new in the full sense of the word, because it is a recent regression, and I *fear* it was introduced as a negative side effect of your fixes for bug 47368. Therefore, could you please take a look at this issue soon (because we want to fix regressions early)? You know best about two these patches ... Sorry for the bad news, and thank you very much! (I am sorry myself that I did not notice this regression earlier, but I seldom use the context menus, and therefore I must have missed it. I will be even more careful in the future ...)
Supplement: The *other* possibility is that there were some changes to Calc/context menu handling in the 3.6 branch between 2012-09-07 and 2012-09-11 -- so please check this, too.
Still happening in 3.6.3.
(In reply to comment #12) > Still happening in 3.6.3. Yes, sorry; and this will not change, until a developer finds time to look into this issue; and only few developers have experience with this special kind of bugs, and their time is especially rare and expensive ;-) For now, the best workaround is to disable BetterSnapTool (or similar tools) while you are working with LibreOffice -- sorry again!
I had the very same problem, took me long to figure out. I still believe it's not something that LibreOffice should be fixing (probably more of RightZoom or that other tool problem). Anyway, I just disabled RightZoom for LibreOffice App and everything works fine. Some additional log info from Console.app: http://bpaste.net/show/leF4KKZEjAnBeh3YfdmV/
It seems that another bug: bug 57245 -- “In OS X Calc hangs if save button used when Cinch is activated (both Cmd-S and menu File->Save work OK” -- was just like the present bug introduced as a negative side-effect of one of the two patches cited in comment #9. Bah ...
Anything with this in the trace: 17 hitTestRunner(com::sun::star::awt::Point, com::sun::star::uno::Reference<com::sun::star::accessibility::XAccessibleContext>) + 433 (in libvcllo.dylib) [0x23e61f1] 17 ScAccessibleTableBase::getAccessibleChild(long) + 131 (in libsclo.dylib) [0x2ec94513] is a duplicate of bug#56937 which needs someone to help test/compile the fix :-) Thanks for the nice report ! *** This bug has been marked as a duplicate of bug 56937 ***
VERIFIED as DUPLICATE: I can no longer reproduce this bug beginning with the 1st available master build after the patch for bug 56937 has been committed: 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 This means that the present bug is really a duplicate of bug 56937, and was fixed by the same commit. Tested on Mac OS X 10.6.8 (Intel), with RightZoom installed and active. @ Michael Meeks: Thank you very much again for fixing bug 56937 (and all its instances, like this one)!