Bug 54580 - Clicking Slide Thumbnail of Non-Focused Window Causes Rearrange/Crash
Summary: Clicking Slide Thumbnail of Non-Focused Window Causes Rearrange/Crash
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
3.6.1.2 release
Hardware: x86-64 (AMD64) macOS (All)
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-09-06 02:38 UTC by Adam Dunn
Modified: 2016-04-16 16:54 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Crash log for bug 54580 (LibO 3.6.1.2 on Mac OS X 10.6.8 Intel) (46.91 KB, text/plain)
2012-09-06 14:58 UTC, Roman Eisele
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Dunn 2012-09-06 02:38:47 UTC
The second half of my bug may very well be related to bug 51023; I'll let you decide.

First half:
Description:
Clicking on a slide thumbnail in the left pane when LibreOffice does not have window focus causes the selected slide to shuffle to the top of the deck (become slide number one).

Reproduction:
Start a new presentation slide show. Create three slides in the show (title them 1, 2, 3 for easy identification). Select slide 3. Bring up another window that grabs focus, but doesn't hide LibreOffice (a small TextEdit window will do). Now that LibreOffice is in the background, click on the thumbnail in the left pane for slide 3. Slide 3 will now be slide 1.

Workaround:
Don't multi-task.

Second half:
Description:
Now that we have rearranged slides, we can click on the thumbnails for the two non-rearranged slides as many times as we want, but any attempts at clicking on the rearranged slide (slide 3 cum 1) will cause LibreOffice to crash.

Reproduction:
Click on slide number 1 (which was originally slide 3). Crash.

Workaround:
???

Platform:
LibreOffice Version 3.6.1.2 (Build ID: e29a214)
OSX Version 10.8.1 Build 12819
Comment 1 Roman Eisele 2012-09-06 14:53:16 UTC
Thank you very much for your bug report, especially for your well-written, step-by-step “reproduction” descriptions!


(In reply to comment #0)
> The second half of my bug may very well be related to bug 51023; I'll let you
> decide.

A good hint; see “Evaluation” below.

> First half:
> Description:
> Clicking on a slide thumbnail in the left pane when LibreOffice does not have
> window focus causes the selected slide to shuffle to the top of the deck
> (become slide number one).
> 
> Reproduction:
> Start a new presentation slide show. Create three slides in the show (title
> them 1, 2, 3 for easy identification). Select slide 3. Bring up another window
> that grabs focus, but doesn't hide LibreOffice (a small TextEdit window will
> do). Now that LibreOffice is in the background, click on the thumbnail in the
> left pane for slide 3. Slide 3 will now be slide 1.

REPRODUCIBLE with
* LibreOffice 3.5.6.2 (Build-ID: e0fbe70-dcba98b-297ab39-994e618-0f858f0),
* LibreOffice 3.6.1.2 (Build ID: e29a214),
both with German langpack installed, on Mac OS X 10.6.8 (Intel).

Maybe not 100% reproducible, but works most times.


> Second half:
> Description:
> Now that we have rearranged slides, we can click on the thumbnails for
> the two non-rearranged slides as many times as we want, but any attempts
> at clicking on the rearranged slide (slide 3 cum 1) will cause
> LibreOffice to crash.
> 
> Reproduction:
> Click on slide number 1 (which was originally slide 3). Crash.

REPRODUCIBLE with
* LibreOffice 3.5.6.2 (Build-ID: e0fbe70-dcba98b-297ab39-994e618-0f858f0),
* LibreOffice 3.6.1.2 (Build ID: e29a214),
both with German langpack installed, on Mac OS X 10.6.8 (Intel).

Again: Maybe not 100% reproducible, but works most times.


EVALUATION:
I will attach a Mac OS log file created for the crash (second half). This log file is nearly _identical_ to the ones for bug 51023 (see
  * attachment 63084 [details]
  * attachment 63290 [details]
; all three crash at
  sd::slidesorter::model::PageDescriptor::GetPage() const + 6
); so I would say that the second half of this bug report is really a duplicate of bug 51023.

In addition, I got the impression that also the first half of this bug report is at least related to bug Thank you very much for your bug report, especially for your well-written, step-by-step "reproduction" descriptions!


(In reply to comment #0)
> The second half of my bug may very well be related to bug 51023; I'll let you
> decide.

A good hint; see below.

> First half:
> Description:
> Clicking on a slide thumbnail in the left pane when LibreOffice does not have
> window focus causes the selected slide to shuffle to the top of the deck
> (become slide number one).
> 
> Reproduction:
> Start a new presentation slide show. Create three slides in the show (title
> them 1, 2, 3 for easy identification). Select slide 3. Bring up another window
> that grabs focus, but doesn't hide LibreOffice (a small TextEdit window will
> do). Now that LibreOffice is in the background, click on the thumbnail in the
> left pane for slide 3. Slide 3 will now be slide 1.

REPRODUCIBLE with
* LibreOffice 3.5.6.2 (Build-ID: e0fbe70-dcba98b-297ab39-994e618-0f858f0),
* LibreOffice 3.6.1.2 (Build ID: e29a214),
both with German langpack installed, on Mac OS X 10.6.8 (Intel).

Maybe not 100% reproducible, but works most times.


> Second half:
> Description:
> Now that we have rearranged slides, we can click on the thumbnails for
> the two non-rearranged slides as many times as we want, but any attempts
> at clicking on the rearranged slide (slide 3 cum 1) will cause
> LibreOffice to crash.
> 
> Reproduction:
> Click on slide number 1 (which was originally slide 3). Crash.

REPRODUCIBLE with
* LibreOffice 3.5.6.2 (Build-ID: e0fbe70-dcba98b-297ab39-994e618-0f858f0),
* LibreOffice 3.6.1.2 (Build ID: e29a214),
both with German langpack installed, on Mac OS X 10.6.8 (Intel).

Again: Maybe not 100% reproducible, but works most times.


EVALUATION:
I will attach a Mac OS log file created for the crash (second half). This log file is nearly _identical_ to the ones for bug 51023 (see
  * attachment 63084 [details]
  * attachment 63290 [details]
; all three crash at
  sd::slidesorter::model::PageDescriptor::GetPage() const + 6
); so I would say that the second half of this bug report is really a duplicate of bug 51023.

In addition, I would guess that also the 1st half of this bug (report) is at least related to bug 51023 -- the strange jump of (in your example) slide 3 to the 1st place is very similar to the broken drag-and-drop of slides in bug 51023.
Comment 2 Roman Eisele 2012-09-06 14:58:10 UTC
Created attachment 66736 [details]
Crash log for bug 54580 (LibO 3.6.1.2 on Mac OS X 10.6.8 Intel)
Comment 3 Don't use this account, use tml@iki.fi 2013-08-07 07:31:38 UTC
Could you please try to reproduce this bug with LibreOffice 4.1, thanks.
Comment 4 QA Administrators 2015-04-01 14:40:10 UTC
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

   *Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later)
   https://www.libreoffice.org/download/

   *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
 
   *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System

Please DO NOT

   *Update the version field
   *Reply via email (please reply directly on the bug tracker)
   *Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 

1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)

http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug 
3. Leave a comment with your results. 
4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 
4b. If the bug was not present in 3.3 - add "regression" to keyword


Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa

Thank you for your help!

-- The LibreOffice QA Team This NEW Message was generated on: 2015-04-01
Comment 5 Adam Dunn 2015-04-01 17:03:30 UTC
I'm no longer seeing the second half of my bug report, so that is fixed, but the first half still applies, with some modification:

I'm now using LibreOffice 4.4.1.2 (build 45e2d...) on OS X 10.10.2. In my original bug report, I said, "Select slide 3. Bring up another window...". This bug doesn't appear to happen as often when slide 3 is selected (it is perhaps 10% reproducible). It happened far more often in LibreOffice 3.6.1.2 when I first submitted the bug report. However, in LO 4.4.1.2, when slide 1 is selected, and another window gains focus, and then the thumbnail for another slide (slide 2 or 3) is clicked, then the bug is about 90% reproducible. Strangely, it doesn't happen every single time - perhaps only 90%. Having any other slide selected (second or third) will almost be unreproducible, but it does happen sometimes (maybe 10%). I haven't determined a pattern to the behaviour.
Comment 6 tommy27 2016-04-16 07:22:44 UTC
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.5 or 5.1.2 https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System

Please DO NOT

- Update the version field
- Reply via email (please reply directly on the bug tracker)
- Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 

1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)

http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug 

3. Leave a comment with your results. 

4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 
4b. If the bug was not present in 3.3 - add "regression" to keyword


Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa

Thank you for your help!

-- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16
Comment 7 Adam Dunn 2016-04-16 16:54:01 UTC
This bug appears to be fixed for me. I'm now running LO 5.1.2.2 on OSX 10.11.4 and unable to reproduce the bug anymore. Works for me! Thanks!