Problem description: LibreOffice crashes if you press command-arrow or option-arrow shortcut keys while editing a database query (in the query "design view" edit window, i.e., not the SQL edit window). Steps to reproduce: 1. Create a new database. Save it somewhere. You don't need to add any data or tables. 2. Click on "Queries" in the main window. Then "Create Query in Design View..." 3. Close the "Add Table or Query" dialog. 3. Click in any cell in the grid that takes text input (i.e., not the "Table" or "Sort" rows, which are drop-down menus). 4. Press option-right/left arrow or command-right/left arrow. Current behavior: LibreOffice crashes. Expected behavior: The cursor should move to the beginning or end of the word or line. LibreOffice should not crash. This bug is also present in OpenOffice 4.0.0. Operating System: Mac OS X Version: Inherited From OOo
On pc Debian x86-64 with master updated today or 4.1 sources updated recently, both with a brand new LO profile, I don't reproduce this. Could you put error logs (see https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#Mac_OSX:_How_to_get_debug_information) in a file and attach it by using this link? https://bugs.freedesktop.org/attachment.cgi?bugid=69162&action=enter
Created attachment 85676 [details] Crash backtrace
On Mac 10.7.5 and LO 4.1.1.2, I don't reproduce this. What LO version do you use? Could you give a try the last one? If you still reproduce this, could you rename your LO directory profile (see https://wiki.documentfoundation.org/UserProfile#Mac_OS_X) and try again?
Yes - this is under LO 4.1.1.2. (Build ID: 7e4286b58adc75a14f6d83f53a03b6c11fa2903) I can reproduce with 10.7.5 and 10.8.4. Both US and Dvorak keyboard layouts. I tried on two different computers with completely different accounts and clean LO profiles.
Created attachment 85693 [details] 10.7.5 Crash backtrace
dhorwood: thank you for your feedback I'll quote the Roman's questionnaire which helped a lot in other bugtrackers: " 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”, 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 * Flavours (from flavours.interacto.net) ... 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 crash go away, and report the results here. " Alex: I put you in cc since you might be interested in this one.
This used to happen with the new template manager on OSX, but that got fixed. I will have a llok and see if the trace is the same. Alex
(In reply to comment #6) Julien: I have tried on two separate systems, and have ensured that "access for assistive devices" is turned off. I don't think that either system has any of the utilities mentioned in your post. Additionally, I have reproduced the crashes on brand new user accounts on both systems.
dhorwood: thank you again for your last feedback. I don't have more question for the moment, i revert the status to UNCONFIRMED. Your turn Alex! :-)
Confirming on LO 4.1.1.2
I see the same crash trace
It seems to be an accelerator key mapping problem.
Can't test this on OSX master at the moment, as attempting to open the Query Designer causes the whole app to crash with a jnilib loading error. Alex
Stuart and Tor to CC More accelerator key problems ? Alex
Created attachment 85956 [details] accelerator key bt Enclosing backtrace
I see this is LO 3.3.4 too, so confirming at least as far back as that.
I could reproduce the problem with 4.2 sources some days ago. I'd like to give a try with master sources but I've got a build problem with mariadb part.
We fixed the crash, but if that keystroke was supposed to do something useful, it still does not now.
Norbert Thiebaud committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=cee813ac6e24b73879312b43695b92fe77b34444 fdo#69162 avoid crashing on Accellerator in poorly initialized context 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.
Norbert Thiebaud committed a patch related to this issue. It has been pushed to "libreoffice-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=233e6a62d12d2d67089f1934777ac41c9fc88238&h=libreoffice-4-3 fdo#69162 avoid crashing on Accellerator in poorly initialized context It will be available in LibreOffice 4.3.2. 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 comment #18) > We fixed the crash, but if that keystroke was supposed to do something > useful, it still does not now. Sorry, correction: it correctly goes to begin/end of word/line now.