Created attachment 61879 [details] Stacktrace Problem description: Steps to reproduce: 1. Create a new empty presentation 2. Add a new slide (Insert - Slide) 3. Go to slide sorter 4. Move slide 2 in front of slide 1 5. Click on "Normal" view Current behavior: Crashes Platform (if different from the browser): Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20100101 Firefox/13.0
NOT REPRODUCIBLE with LibreOffice 3.5.3.2 (Build ID: 235ab8a-3802056-4a8fed3-2d66ea8-e241b8), Spanish langpack installed, on MacOS X 10.6.8 German UI. NOT REPRODUCIBLE with LibreOffice 3.5.4.1 (Build-ID: 7306755-f4f605c-738527d-1cf4bc1-9930dc8), German langpack installed, on on MacOS X 10.6.8 German UI. Following the steps given in the original description, everything works for me as expected. There must be some special condition which makes LibO crash for the original reporter. But what one? ... Can someone else reproduce this crash?
Similar to Bug 48101 - "EDITING: Corrupted visuals and crash after switching to Normal from Slide Sorter after drag-and-drop of slides". Related?
Bug 47569 - "Impress crashes when switching from the notes-view to normal-view" describes a similar issue. Now bug 47569 is marked as a duplicate of our famous bug 47368, what means that bug 47569 happens only when some accessibility utility is enabled on MacOS. @Frank Winklmeier: Do you have any MacOS accessibility utility enabled? This means, in the MacOS System Preferences, in the "Universal Access" (German "Bedienungshilfen") section, do you have enabled "Voice over" or "Enable access for assistive devices" or something else? Thank you for your answer!
Yes, that's it. I had "Enable access for assistive devices" enabled because that is required by BetterTouchTool. I confirm that disabling this option fixes the problem. By the way, this got introduced with LibreOffice 3.5. I successively downgraded from 3.5.3->3.5.2->3.5.1->3.5.0->3.4.6 and all 3.5.X version showed this bug but not 3.4.X. But even for 3.4.X it only disappeared after I wiped my user profile.
Due to comment #4, I mark this bug as a duplicate of our famous bug 47368, just like bug 47569 and other bug reports about crashes on MacOS with "Universal Access"/accessibility enabled. Modified 'Version' according to comment #4: this issue is reproducible for the 1st time in LibO 3.5.0, but not in 3.4.x. @Frank Winklmeier: Thank you very much for your fast answer! Marking this bug as a duplicate does not make your bug report worthless etc. Your report is still a valuable contribution, and every additional duplicate should increase the weight of bug 47368 -- maybe some developer will finally find a way to fix it ... (This seems difficult, however, because bug 47368 is a really weird affair ;-( *** This bug has been marked as a duplicate of bug 47368 ***
For the record: I tried to reproduce this bug with Norbert’s debug version of 3.6.0.2+ and "Enable access for assistive devices" checked and RightZoom installed, but I could not manage to reproduce the crash. It seems possible that things have changed here, because we also have bug 51023 in this area ... So maybe we need to get bug 51023 fixed first, and then we can see what is about this present bug.
*** Bug 52014 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > By the way, this got introduced with LibreOffice 3.5. I successively > downgraded from 3.5.3->3.5.2->3.5.1->3.5.0->3.4.6 and all 3.5.X version > showed this bug but not 3.4.X. Therefore added “regression” keyword. > But even for 3.4.X it only disappeared after I wiped my user profile. Interesting; maybe just a coincidence, or really important ...
*** Bug 47569 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > *** Bug 47569 has been marked as a duplicate of this bug. *** Bug 47569 is about a crash which occurs when switching back from “Notes” view to “Normal” view, and has no stack trace, but it seems still very probably that it is the same bug as the present issue. → Therefore adapted Summary, a) to make clear that the switching of the tab back to “Normal” is the moment when the crash occurs (cf. the stack trace: IMHO the crash occurs somewhere in the drawing process of the tab), b) to add in parenthesis the alternative of switching back from “Notes” view, c) to mention explicitly the relation to Mac OS accessibility features.
REOPENED, because a) it is not sure if this bug was really a duplicate of bug 47368 (which is fixed now, BTW; fix will be in 3.6.2 and 3.7.0!) b) the bug is now more or less confirmed by the two duplicates.
@ Frank Winklmeier, @ Paulo, @ Reiner Anselm: I am currently doing a survey of all bugs related to Mac OS accessibility features. This bug which was reportet by you (all three) is one of the remaining issues on my list, but I can’t make any substantive progress here because I still can’t reproduce it myself -- even when I check “Enable access for assistive devices” and activate RightZoom or BetterTouchTool ... Therefore we need your help to make progress here. Please, can you (every single one of you ;-) try the following: 1) Can you please download the newest LibreOffice release candidate (3.6.2.1) from http://www.libreoffice.org/download/pre-releases/ and install it and try if you can still reproduce this kind of crash (with “Enable access for assistive devices” checked, and/or BetterTouchTool running, or whatever kind of utility you used when you first experienced that crash? Explanation: We have fixed two or three very important problems related to Mac OS accessibility features in this release, so there is a chance that the bug reported by you was fixed, too. But we NEED to know if it is actually fixed nor not ... 2) Please report here (in an additional comment to this bug report) if you can still reproduce the crash with LibreOffice 3.6.2.1. *IF* you can still reproduce it, a) please attach crash the crash log / debug information / stack trace which Mac OS X displays in a window after the crash. (If you need any explanations about where exactly this information is, and how to attach it here, please mail me directly: bugs@eikota.de, and I will send you an explanation.) This allows us to verify if you all experience 100% the same crash, or if there is some variation. b) Please also mention which options in the System Preferences / “Universal Access” (German: “Bedienungshilfen”) control panel you have activated: “Enable access for assistive devices”? “Voice over”? “Zoom” Or ...? Or nothing? A screenshot of the complete “Universal Access” window with all settings would be the easiest way to do that. c) And please also mention which window management utilities/tools you use: BetterTouchTool, RightZoom, Cinch, Moom, SnapIt, or anything similar? (If you don’t understand what I mean here -- this is a bit difficult to explain ;-), don’t hesitate, ask me, and I will give a more detailed description ;-) I know this is much work, but it would be very very helpful if you could try this and report all results in detail, so *please* help us! ;-) This is the only way to get this bug fixed. Thank you very much in advance!
@Roman, thank you very much for your engagement! As to your question: The bug Frank Winklmeier had reported in May still exists in 3.6.2.1. The steps to reproduce are the same: 1. Create a new presentation 2. Add two (or more) slides 3. In the left pane, drag slide 3 behind slide 1 4. Click any other slide -> Crash. I will attach the crash-report as an attachment. I have no (!) accessibility features enabled. And I do not use any window management tools. But there are good news too: The bug I reported, a crash when switching from notes-view to normal is no more reproducible. Please do not hesitate to contact me if you need further information. This bug is very annoying, you cannot use impress for "mission critical" purposes, because the moment comes always that you will not keep in mind that you must not sort slides by draging! I lost too much data in the meantime....
Created attachment 67334 [details] Crash report
One additional hint to reproduce: Sometimes you need to click 3 or more times in different slides in the left pane until LO crashes.
@ Reiner Anselm : Thank you very much for your fast answer!!! But I got a question ;-) You write: (In reply to comment #13) > The bug Frank Winklmeier had reported in May still exists in 3.6.2.1. > The steps to reproduce are the same: > 1. Create a new presentation > 2. Add two (or more) slides > 3. In the left pane, drag slide 3 behind slide 1 > 4. Click any other slide -> Crash. (In reply to comment #15) > Sometimes you need to click 3 or more times in different slides in the left > pane until LO crashes. Are these steps really exactly the same as reported by Frank Winklmeier? If I understand his description (comment #0) and the stack trace in “his" original crash report (attachment 61879 [details]) correctly, his crash occured when switching back from Slide sorter view to “Normal” view. But “your” crash happens after dragging slides and then clicking 1, 3, “or more times in different slides in the left pane”. Of course, this is very similar, but IMHO there is a little difference. This idea is confirmed by the stack traces in the log files: while Frank’s log (attachment 61879 [details]) shows that the crash happened when re-drawing the window/pane, your log file (attachment 67334 [details]) shows a completely different stack trace: “your” crash happens somewhere in the slidesorter code. Therefore I would guess we have two different bugs here ;-(. But there are good news, too: the stack trace in your log file is identical to the stack traces attached to bug 51023, which is also (see the description) very very similar to your steps to reproduce. *This* bug is, of course, reproducible *without* any accessibility features enabled, just as you write: > I have no (!) accessibility features enabled. And I do not use any window > management tools. So I would suggest a) that the crash you have reproduces is identical to bug 51023, not to the original type of crash reported by Frank (and by you and Paulo in your bug reports); and b) that the original bug reported by Frank (and by you and Paulo) is really no more reproducible (*), as you write: > But there are good news too: The bug I reported, a crash when switching from > notes-view to normal is no more reproducible. What do you think? @ Frank Winklmeier, @ Paulo: Can you still reproduce “your” bugs with LibreOffice 3.6.2.1?
Downloading LO 3.6.2.1 RC. Will check and report back tomorrow at the latest. - Paulo.
@Roman yes, you're right: I have read the comment #0 again and I see that this is another scenario. So I would agree with you that 50147 and 51023 are identical. These bugs are apparently not linked with any accessibility features. So I really hope that we are moving towards a solution.
LO 3.6.2.1 build: ba82ccc passed OK, no crashes in Impress or Word! That said, I have upgraded from Lion to Mountain Lion. I don't have another Lion machine to test the behaviour under the exact same circumstances I first reported. - Paulo.
@Reiner, @Paulo: Thank you very much for testing again and for your quick answers! Let’s wait a bit, if Frank Winklmeier also finds time to answer ... (In reply to comment #18) > So I would agree with you that 50147 and 51023 are identical. > These bugs are apparently not linked with any accessibility features. Wait a minute -- there is again a little difference ;-) 1) IMHO the issue which you reproduced in comment #13 is identical to bug 51023 -- yes, and *this* issue is not linked to accessibility features. 2) But the original issue of bug 50147 (as reported by Frank in comment #0) was not identical to bug 51023, but identical to bug 52014 and bug 47569, reported by you (Reiner) and Paulo, and this issue was related to Mac OS accessibility features. But this is just a difference of bug handling, of course. The important thing is that no one of the three accessibility-related bugs bug 50147 = bug 52014 = bug 47569 seems to be reproducible anymore (just waiting for Frank’s answer!), and this allows us to close this (present) bug as RESOLVED/WORKSFORME, and then to concentrate on getting the remaining bug 51023 fixed, too.
I am currently using 3.6.1.2 (Build ID: e29a214) (NOT 3.6.2.1) and can no longer reproduce the problem I originally reported in comment #0. Since this release is without the recent accessibility fixes I am not sure what to make out of this. I think you can probably close this bug report then.
@ Frank: Thank you for your answer! And thank you all three for your fast and precise answers! This makes bugwrangling much easier (often the original reporter of a bug never answers to any questions, making it impossible to process a bug report correctly). -> Because of Frank’s, Paulo’s, and Reiner’s answers, and because of my own test results, I set the status of this bug report to RESOLVED/WORKSFORME, as appropriate (cf. explanation in comment #20). The kind crash of crash described in comment #13 is a different kind of crash (cf. comment #16, comment #18), and is handled separately as bug 51023. Anybody, plese reopen this bug report only (!) if you can reproduce exactly (!!!) the same crash as described in comment #0 with LibreOffice 3.6.1 or newer. If you just experience a similar crash, please file a *new* bug report for it. Thank you very much!