Bug Hunting Session
Bug 33945 - Impress: Selection of slides is broken
Summary: Impress: Selection of slides is broken
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium minor
Assignee: Not Assigned
Depends on:
Blocks: Slide-Page-Pane
  Show dependency treegraph
Reported: 2011-02-05 13:29 UTC by mike.hall
Modified: 2017-09-30 17:00 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description mike.hall 2011-02-05 13:29:40 UTC
Steps to reproduce:
Create a new presentation with three slides
In normal view, click first slide to select
Ctrl click third slide

Expected behaviour:
Slides 1 & 3 are selected

Actual behaviour:
Slides 2 & 3 are selected

Presumably this is a regression from OOo 3.2.1 but I haven't tested that.

The described behaviour occurs in both normal and slide sorter view.

Shift click is also not working.

You can after a set of clicks eventually get the right slides selected, but the behaviour is decidedly odd.

Believe this should be a blocker for 3.3.1, or if it is too late, certainly for 3.3.2.
Comment 1 mike.hall 2011-02-05 14:35:30 UTC
On reopening the test presentation, on first try the example given worked correctly, but clicking around, I soon get to the same inconsistent behaviour...
Comment 2 mike.hall 2011-02-07 00:11:48 UTC
Bug 14850 may possibly be related
Comment 3 Thorsten Behrens (CIB) 2011-02-07 02:59:02 UTC
Cannot seem to reproduce in 3.3.0 - tried windows and linux. any chance to play
some more, and figure out the distinguishing moments, for when it happens your
side, and when not (fresh office instance, clicking really fast, stuff like
Comment 4 mike.hall 2011-02-07 03:33:00 UTC
Thanks. It's very inconsistent for me. Sometimes works initially (ie after opening Impress from scratch) and broke after a fairly small number of clicks with further experience this morning. Unlikely to be related to click speed.

Will experiment some more across several PCs with XP and Vista, also with 2.3.1. Target response by 14 Feb as I have no more time for a few days.
Comment 5 mike.hall 2011-02-13 01:05:15 UTC
I have done a considerable amount more testing. On the three systems tested selection is generally broken:
3.3.1 on Vista
3.3.0 on XP
OOO 3.1.0 on Vista (my wife's PC)

All show similar bizarre selection patterns, so this is not a regression, though 3.1.0 did seem to be slightly better, eg selection in slide sorter seemed to be working properly.

What I see does not depend on which presentation is open. I have been working for testing with a small presentation which is now four very simple slides.

The remainder of this report applies to 3.3.1 on Vista, installed last night and I have rebooted since to change from no quickstarter to quickstarter to see if that made a difference (it didn't).

The simplest demo of this problem is:

In normal view select slide 2
Click slide sorter - slide 2 is still selected
Click slide 3 to select
Click outline view - slide 2 is selected [bug] and this selection is preserved  through other views

In normal view select slide 2
Click slide sorter - slide 2 is still selected
Click slide 3 to select
Click normal view - slide 3 is selected [correct] and this selection is preserved through other views

In normal view select slide 2
In succession click the other views including handout, stopping at slide sorter
In slide sorter view slide 2 is still shown as selected [correct]
Click normal. Slide 1 is now selected [bug] and this selection is preserved through other views, including slide sorter

Using Ctrl+Click and Shift+Click to select slides in any view gives inconsistent and often bizarre selections. Selection sometimes works as expected, but more often than not it doesn't. Sometimes Ctrl Click on a selected slide selects the inverse selection.

Selections are preserved between normal and outline views, but moving to notes or slide sorter generally results in only the fulcrum slide (ie the first slide that was selected) being selected [bug] - selections should be preserved between views. It is sometimes possible to have a selection in one view, click to another to see a single slide selected, but when clicking back to the previous view, the original selection is still there, eg select all slides with Ctrl+A in normal view. This selection is preserved in outline view. In slide sorter view, slide 1 is selected. Click back to normal, and all slides are still selected. Similarly if no slides are selected.

I observe similar behaviour on the other systems.

As far as I know, there is nothing particularly odd about the setup of the PCs tested, or of the Lo/OOo installations. All OS versions are updated to the latest Windows Update revisions. We have Sugarsync and Cloudmark active and we use Norton 360. All are Dell boxes, a portable and two desktops. What else can I do to demonstrate this problem for you? It's an example of needing to spend a lot of support time on one issue, which if I costed my time sensibly would have paid for MS Office several times over, where I wouldn't have this problem! (I had years of PPT experience before retirement).
Comment 6 Petr Mladek 2011-05-11 07:26:45 UTC
I agree that it is annoying but I do not think that it is a blocker. There are no duplicates or other people in CC, so I think that most users use another workflow and this problem is not critical for them => I lower priority and severity a bit.

Thanks for the simple scenarios in comment #5. I am able to reproduce them. It might help to fix this bug.
Comment 7 mike.hall 2011-05-29 01:34:12 UTC
@Petr Mladek

Thanks for your response - sorry for this slow response - holidays.

I'm not changing anything, but it seems to me that selection is such a fundamental part of an application that not rating any bugs as blockers is rather strange. Basically I don't care about the priority, but it would be good to have it fixed.

Regarding other not noticing, I can well imagine that they simply thought they had clicked the wrong thing, as I did for some time until I decided to look at it more carefully and perhaps as you did too until you followed the example.
Comment 8 whynot 2011-10-13 07:30:24 UTC
I am using LibreOffice 3.4.3 almost on a daily basis. I would go as far as saying that slide selection, as well as slide cut&past, as well as slide drag&drop is VERY broken. It is broken so badly that data the document integrity can easily be compromised. Therefore, I think this should be considered a show stopper bug. 

I see so many different modes of behavior (both in the "Normal" and in the "Slide Sorter" views) that I don't really know if this is one bug or several. Also, the behavior is quite unpredictable. I am also getting a significant amount of crashes of LibreOffice. 

A few examples: 
1) When I do drag&drop one slide from one document to a second one. Let's say I want the slide to be place between slides 6 and 7 of the target presentation. While I do the dragging, the slide is shown as a little thumbnail between slides 6 and 7 as intended. However, when I "drop" it by releasing the mouse button, it often shows up in the completely wrong location (often more toward the beginning of the presentation. 

2) If I do the same as described in (1), sometimes the correct preview of the slide is shown while dragging. However, when I finally release the mouse button (drop), a different (!) slide from the source presentation is actually copied into the target presentation. This is dangerous and can lead to data loss. Especially when the slide is then deleted from the source presentation

3) When I try to drag and drop slides in one presentation, sometimes it works as intended, sometimes doing the same clicks just selects slides. 

4) The behavior of selecting multiple slides using the shift or ctrl keys is unpredictable. 

The all appears very broken, and even unprofessional. I am sorry I don't have more time right now for more rigorous testing.
Comment 9 whynot 2011-10-13 07:42:01 UTC
... and I forgot to say that this is observed in kubuntu natty (32 bit); I observed similar behavior in kubuntu (lucid, LTS). 

I apologize for a few typos. What I meant with "data/document compromised" is that if the wrong slide gets pasted and then the "right" slide is deleted, as described in (2), data can be lost. Also with "integrity" I mean that slides get pasted in the wrong place of the document. Sometimes this appears as if nothing was pasted (because it goes unnoticed). Then, something is pasted again, again in the wrong place, and the mess just gets bigger. 

I welcome the new functionality in LO with respect to OOo (slide preview while drag&drog). OOo was quite simple and unsatisfying in its performance and functionality in this respect. However, LO currently seems much more broken in this respect than OOo was.
Comment 10 Björn Michaelsen 2011-12-23 11:43:14 UTC Comment hidden (obsolete)
Comment 11 Björn Michaelsen 2011-12-23 17:00:32 UTC
needinfo keyword redundant by needinfo status.
Comment 12 mike.hall 2011-12-24 04:35:30 UTC
Still behaving as described in 3.5.0b3, therefore have set status back to NEW
Comment 13 rigelan 2012-02-12 11:51:44 UTC
This is also occurring on Windows Vista.  

It seems like some of the odd selecting behavior seems related to where the mouse is located.

If I try to select from the slideshow column on the left by holding down shift and pressing up or down - then it will think it is selecting - but will not select if the mouse cursor is residing on top of the list somewhere.

If I remove the mouse cursor so it is not on top of the slide selection column - I get better selection ability, and am able to copy and paste parts of slideshows from one document to another.
Comment 14 rigelan 2012-02-12 11:52:15 UTC
Sorry - Version 3.4.5 on Vista.
Comment 15 rigelan 2012-02-12 12:05:22 UTC
Select the last slide in the list, keep your mouse on the last slide - hold shift and press up to select about 4-5 slides.  After 2 or 3 slides, it does not stay selected.  

I tried it by starting at the top and selecting downward - selecting works if I am going that direction - but does not work if I start at the bottom and select upward.
Comment 16 rigelan 2012-02-12 12:58:31 UTC
After downloading 3.5.0 rc3 - It appears like my bug is fixed.  So - The original poster will have to check his selection bug in Impress.
Comment 17 Julien Nabet 2012-05-12 06:21:42 UTC
On pc Debian x86-64 with branch 3.5 updated today, I don't reproduce this problem.
Could you give a try to a newer version (for example 3.5.3) ?
Comment 18 mike.hall 2012-05-12 15:01:23 UTC
The problems are not the same as before, but selection is still substantially broken.

Clicking on Handout resets selection to slide 1, irrespective of selection. In the following, do not click on Handout. (Also the Handout view shows only as an outline, ie no slide content is displayed, which is probably a regression).

The simplest demo of this problem is:

In normal view select slide 2
Click slide sorter - slide 2 is still selected
Click slide 3 to select
Click outline view - slide 2 is shown selected on the slides column [bug] but slide 3 is selected in the outline
Click Normal - slide 3 is selected and this selection is preserved through other views

In normal view select slide 2
Click slide sorter - slide 2 is still selected
Click slide 3 and ctrl+click slide 7 to select 2 slides
Click normal view - only slide 3 is selected [bug] and this selection is
preserved through other views

Similarly a selection of 3 & 7 in normal view is changed to 3 only in slide sorter, but clicking back to normal, 3&7 are still selected

If you select multiple slides in Slide Sorter and then click between Slide Sorter, Outline and Normal, you occasionally get bizarre selections, sometimes with slides selected which haven't been selected in any view.

There is still something seriously wrong. Using Win64/LO for this test.
Comment 19 mike.hall 2012-12-18 13:36:21 UTC
No change in LO 4.0.0 beta eg
In normal view select slides 1 3 5
Click slide sorter - slide 1 selected
In slide sorter view, select slides 1 4 7
Click normal view - slides 1 3 5 are selected
Click slide sorter - slide 1 selected

Comment 20 bfoman (inactive) 2013-08-14 21:42:41 UTC
Confirmed with:
Build ID: 087a610fcd5c0c354a9ed6bfccd3451b667d62a3
TinderBox: Win-x86@6-debug, Branch:master, Time: 2013-08-04_21:41:24
Windows 8.1 Enterprise Preview 64 bit

Confirmed A and B from comment 18. Very annoying...
Comment 21 QA Administrators 2015-04-01 14:40:13 UTC Comment hidden (obsolete)
Comment 22 Buovjaga 2015-04-20 15:53:36 UTC
Reproduced steps in comment 18.
Could not reproduce steps in description.

Lowered priority per https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg

Win 7 Pro 64-bit Version: (x64)
Build ID: 211c12b9c64facd1c12f637a5229bd6a6feb032a
TinderBox: Win-x86_64@42, Branch:master, Time: 2015-04-18_01:51:17
Locale: fi_FI

Ubuntu 14.10 64-bit 
Build ID: afb82d3729bda2754d0add08cc6c4dce1dc76d59
TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2015-04-14_00:05:04
Locale: en_US
Comment 23 Julien Nabet 2015-04-20 16:04:08 UTC
Following Beluga's comment, does someone reproduce this with recent LO version (4.4.2 or at least 4.3.6)?
Comment 24 QA Administrators 2015-05-06 14:21:17 UTC Comment hidden (obsolete)
Comment 25 mike.hall 2015-05-06 16:51:25 UTC
The essence of this error remains in on Win 7.

For example, with a 7 slide test pressy:

In Normal view, select slides 5 & 7
1 Click 'slide sorter' -> slide 5 is selected (should be 5 & 7)
2 Click 'normal' -> slide 5 is selected (OK)
3 Click 'slide sorter' and select slides 5&7
4 Click 'normal' -> slides 5 & 7 are selected (OK)
5 Click 'slide sorter' -> slide 5 is selected (as 2)

In summary after further testing:
Clicking between 'normal', 'outline' and 'notes' is working.
Clicking from any of those to 'slide sorter' always results in the lowest slide number being selected (error)
Clicking from 'slide sorter' to 'normal', 'outline' or 'notes' works correctly with a single slide selected
Clicking from  'slide sorter' to 'normal', 'outline' or 'notes' works correctly if the slides selected are a subset of those selected in 'normal', 'outline' or 'notes', then clicking on 'slide sorter', reselecting some of those previously selected and clicking back to 'normal', 'outline' or 'notes'
Clicking from  'slide sorter' to 'normal', 'outline' or 'notes' works incorrectly if the slides selected are not a subset of those selected in 'normal', 'outline' or 'notes', then clicking on 'slide sorter'. Making a selection other than from those previously selected and clicking 'normal', 'outline' or 'notes' usually leads to the lowest number slide being selected. On occasions the selection is more bizarre.
From any other view to 'handouts' and then back to another view, slide 1 is always selected, irrespective of the original selection.

Selections are indeed generally slightly more logical than originally reported, but they remain inconsistent and broken. I continue to believe that incorrect selection behaviour is a serious bug. I do not understand how it can take so much effort and repeated re-testing to keep this bug open. It would be really good to fix it!
Comment 26 Buovjaga 2015-05-06 17:01:04 UTC
Well this should not have been set to NEEDINFO in any case.
Comment 27 QA Administrators 2016-09-20 09:36:58 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.1.5 or 5.2.1  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)


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 helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team