Download it now!
Bug 50147 - EDITING: CRASH when switching from Slide Sorter (or Notes?) view to Normal view, with Mac OS X accessibility features enabled
Summary: EDITING: CRASH when switching from Slide Sorter (or Notes?) view to Normal vi...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
3.5.0 release
Hardware: x86 (IA32) Mac OS X (All)
: medium critical
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords: regression
: 47569 52014 (view as bug list)
Depends on:
Blocks: a11y-macOS
  Show dependency treegraph
 
Reported: 2012-05-20 08:54 UTC by Frank Winklmeier
Modified: 2013-11-15 23:18 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Stacktrace (49.84 KB, text/plain)
2012-05-20 08:54 UTC, Frank Winklmeier
Details
Crash report (59.12 KB, text/plain)
2012-09-18 16:39 UTC, Reiner Anselm
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Winklmeier 2012-05-20 08:54:27 UTC
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
Comment 1 Roman Eisele 2012-05-23 11:59:34 UTC
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?
Comment 2 Roman Eisele 2012-05-23 12:02:37 UTC
Similar to Bug 48101 - "EDITING: Corrupted visuals and crash after switching to Normal from Slide Sorter after drag-and-drop of slides". Related?
Comment 3 Roman Eisele 2012-05-23 12:12:04 UTC
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!
Comment 4 Frank Winklmeier 2012-05-23 12:27:49 UTC
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.
Comment 5 Roman Eisele 2012-05-24 00:19:29 UTC
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 ***
Comment 6 Roman Eisele 2012-07-24 08:32:40 UTC
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.
Comment 7 Roman Eisele 2012-09-11 16:02:01 UTC
*** Bug 52014 has been marked as a duplicate of this bug. ***
Comment 8 Roman Eisele 2012-09-18 14:54:34 UTC
(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 ...
Comment 9 Roman Eisele 2012-09-18 15:32:03 UTC
*** Bug 47569 has been marked as a duplicate of this bug. ***
Comment 10 Roman Eisele 2012-09-18 15:43:20 UTC
(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.
Comment 11 Roman Eisele 2012-09-18 15:45:15 UTC
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.
Comment 12 Roman Eisele 2012-09-18 16:02:06 UTC
@ 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!
Comment 13 Reiner Anselm 2012-09-18 16:30:39 UTC
@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....
Comment 14 Reiner Anselm 2012-09-18 16:39:06 UTC
Created attachment 67334 [details]
Crash report
Comment 15 Reiner Anselm 2012-09-18 16:40:34 UTC
One additional hint to reproduce:
Sometimes you need to click 3 or more times in different slides in the left pane until LO crashes.
Comment 16 Roman Eisele 2012-09-18 17:14:11 UTC
@ 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?
Comment 17 Paulo 2012-09-18 17:25:46 UTC
Downloading LO 3.6.2.1 RC.  Will check and report back tomorrow at the latest.
- Paulo.
Comment 18 Reiner Anselm 2012-09-18 18:30:08 UTC
@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.
Comment 19 Paulo 2012-09-18 21:54:13 UTC
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.
Comment 20 Roman Eisele 2012-09-19 09:27:59 UTC
@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.
Comment 21 Frank Winklmeier 2012-09-19 10:02:45 UTC
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.
Comment 22 Roman Eisele 2012-09-19 13:13:31 UTC
@ 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!