Bug 126322 - [UI] Using the scrollbar can start slide reordering
Summary: [UI] Using the scrollbar can start slide reordering
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
6.2.5.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Slide-Page-Pane
  Show dependency treegraph
 
Reported: 2019-07-10 06:59 UTC by zigazou
Modified: 2023-12-30 10:09 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
A 19 second video showing the bug in action (1.33 MB, video/mp4)
2019-07-10 06:59 UTC, zigazou
Details

Note You need to log in before you can comment on or make changes to this bug.
Description zigazou 2019-07-10 06:59:40 UTC
Created attachment 152700 [details]
A 19 second video showing the bug in action

Hi!

When in normal view, using the scrollbar on the slides list can start slide reordering.

To reproduce :

- open a presentation with enough slides to enable the vertical scrollbar
- go down in the slides list
- select one slide by clicking on its thumbnail
- (no mouse button is down at this point)
- now use the scrollbar to go up in the slides list
- while going up (the left button still down), let the cursor go out of the scrollbar area, above the slide thumbnails
- near the top of the list, just release the left mouse button
- the UI now thinks that you have tried to reorder a slide though no mouse button is down
- you can cancel by hitting the ESC key

This bug is easier to see than to read, that's why I have attached a video :

- 00:04: click on the 66th slide
- 00:07: mouse left button down on the vertical scrollbar
- 00:08-00:09: while mouse left button is kept down, the mouse pointer goes up reaching the 7th slide
- 00:09: mouse left button is released
- 00:09-00:15 the slide reordering is activated
- 00:15: the ESC key is hit, the slide reordering is cancelled.
Comment 1 Xisco Faulí 2019-07-31 10:02:52 UTC
Hello,
so just to be clear, you hit ESC before moving slide 66 to position 7 or after it?
Is the slide moved to the new position?
Comment 2 zigazou 2019-07-31 19:19:24 UTC
*so just to be clear, you hit ESC before moving slide 66 to position 7 or after it?*

In fact, the UI acts as if I had started a drag and drop of slide 66. The problem is that the drag and drop is considered active (in action) though the mouse left button has already been released (which would normally end the drap and drop, thus effectively moving the slide).

The only way I have found to cancel this erroneous drag and drop is to hit ESC.

Thus ESC is the very last action.

*Is the slide moved to the new position?*

The ESC key cancels the drag and drop or move of the slide. Therefore the slide is not moved at all.

What I'm trying to achieve is to go to the top of the slide list when I'm at its bottom, I don't want to move any slide.
Comment 3 QA Administrators 2019-08-01 03:37:34 UTC Comment hidden (obsolete)
Comment 4 Oliver Grimm 2019-12-29 22:16:59 UTC
confirmed here on
Version: 6.3.4.2.0+
Build-ID: 1:6.3.4-2
CPU-Threads: 2; BS: Linux 5.3; UI-Render: Standard; VCL: kde5; 
Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE
Calc: threaded

This bug only occurs when one "lets the cursor go out of the scrollbar area, above the slide thumbnails", as the reporter mentioned.

To reproduce try to 
1) keep the mouse pointer along the slider while dragging it upwards VS
2) move the mouse pointer left into the slides area WHILE dragging it upwards.

Expected behavior is that starting to drag the slider upwards should disable a possible drag'n'drop of slides. Try the same in any other application (e.g. any file explorer) that features drag'n'drop and has a vertical scrollbar to get a feeling for this bug.
Comment 5 QA Administrators 2021-12-29 03:57:43 UTC Comment hidden (obsolete)
Comment 6 QA Administrators 2023-12-30 03:13:34 UTC
Dear zigazou,

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 with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

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) from https://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: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug