On reopening the test presentation, on first try the example given worked correctly, but clicking around, I soon get to the same inconsistent behaviour...

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
that)?

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.

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:

A.
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

B.
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

C.
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).

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.

@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.

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.

... 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.

Still behaving as described in 3.5.0b3, therefore have set status back to NEW

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.

Sorry - Version 3.4.5 on Vista.

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.

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.

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) ?

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:

A.
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

B.
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 3.5.3.2 for this test.

No change in LO 4.0.0 beta eg
A.
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

....etc

Confirmed with:
Version: 4.2.0.0.alpha0+
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...

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: 5.0.0.0.alpha0+ (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 
Version: 4.5.0.0.alpha0+
Build ID: afb82d3729bda2754d0add08cc6c4dce1dc76d59
TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2015-04-14_00:05:04
Locale: en_US

Following Beluga's comment, does someone reproduce this with recent LO version (4.4.2 or at least 4.3.6)?

The essence of this error remains in 4.4.3.2 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!

Well this should not have been set to NEEDINFO in any case.

(In reply to mike.hall from comment #25)
> In Normal view, select slides 5 & 7
> 1 Click 'slide sorter' -> slide 5 is selected (should be 5 & 7)

Seeing this too.

> 2 Click 'normal' -> slide 5 is selected (OK)

Nope, it's back to 5 & 7 for me - weird!

> 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)

Indeed.


> Clicking from  'slide sorter' to 'normal', 'outline' or 'notes' works

So, not exactly as expected, i.e. I see Impress restoring the normal-view selection it had suppressed before.


> From any other view to 'handouts' and then back to another view, slide 1 is
> always selected, irrespective of the original selection.

Not for me (at least - assuming you meant Master Handouts).

> Selections are indeed generally slightly more logical than originally
> reported, but they remain inconsistent and broken. 

Yes.

Tested with:

Version: 6.3.2.2
Build ID: 1:6.3.2-1
CPU threads: 4; OS: Linux 5.2; UI render: default; VCL: gtk3; 
Locale: he-IL (en_IL); UI-Language: en-US

No bug as reported, still a bug in 7.1+ per Comment 25 but that's bug 33980. 
Not reading all but I'll close.

*** This bug has been marked as a duplicate of bug 33980 ***