Bug 105320 - Dragging (reordering) slides on the Slides pane deletes slides instead (gtk3?)
Summary: Dragging (reordering) slides on the Slides pane deletes slides instead (gtk3?)
Status: RESOLVED DUPLICATE of bug 118302
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
5.2.3.3 release
Hardware: All Linux (All)
: medium critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Slide-Page-Pane GTK3
  Show dependency treegraph
 
Reported: 2017-01-14 01:42 UTC by Octavio Alvarez
Modified: 2018-08-02 00:53 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Screencast with a bunch of attempts (226.71 KB, video/x-msvideo)
2017-03-12 22:48 UTC, Aron Budea
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Octavio Alvarez 2017-01-14 01:42:39 UTC
Description:
Dragging (reordering) slides on the Slides pane causes data loss.

I present a consistent case where dragging to the bottom in a new presentation always erases the slide.

Steps to Reproduce:
1. New presentation

2. Type "A" as the title of the initial slide. To get out of typing mode, click on the slide but outside of the title box.

3. On the Slides pane, right-click in the initial slide and choose New Slide.

4. Type "B" as the title of the newly created slide. To get out of typing mode, click on the slide but outside of the title box.

5. On the Slides pane, drag slide 1 below slide 2.



Actual Results:  
Slide 1 gets deleted.

Expected Results:
Slide 1 should become the second slide.


Reproducible: Always

User Profile Reset: No

Additional Info:
Note how the "Undo" button refers to the action as "Delete Slide".

Also, note that if you get out of the title boxes using the Escape key after typing in step 4, this problem does not occur.

I'm marking this as critical because when the presentation already has many slides, it may be difficult to notice that the slide got deleted. The user would continue to work --happened to me-- thinking that the slide was properly reordered, which means that recovering the slide means having to go through Undo History, undoing any work done afterwards and having to be extra careful of not making any accidental modification *at all* to the presentation. Any accidental modification to the presentation means losing the redo history, and losing the work the user had to undo to recover the lost slide.

For practical purposes I am classifying this as "data loss".


User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.75 Safari/537.36
Comment 1 Julien Nabet 2017-01-14 15:41:34 UTC
On pc Debian testing x86-64 with LO Debian package 5.2.4, I don't reproduce this.

Could you give a try to 5.2.4 LO version?
Comment 2 m.a.riosv 2017-01-14 21:26:07 UTC
I can't reproduce.
Version: 5.2.5.1 (x64)
Build ID: 0312e1a284a7d50ca85a365c316c7abbf20a4d22
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
Locale: es-ES (es_ES); Calc: group
Comment 3 Octavio Alvarez 2017-01-17 22:52:40 UTC
Ok, thanks for your feedback. I found the following interesting information:

1. It doesn't always happen now but after creating some slides and dragging the first one to random locations between slides or even over existing slides, causes the bug to eventually happen, losing the slide.

2. I tried resetting my profile and the problem doesn't go away.

3. Then I upgraded to 5.2.4.2.1+ (Debian Sid) and it still happens (also, not always, but eventually).

4. The problem happens under VCL: gtk3, but not gtk2. I was testing on my laptop and I couldn't reproduce it! ThenI noticed the following difference in the About box: VCL: gtk3 vs VCL: gtk2.

I noticed that dragging on a gtk2 VCL turns the cursor into a "No" when sliding over adjacent slides. I noticed that dragging on a gtk3 VCL turns the cursor into a hand.

I installed libreoffice-gtk3 on my laptop and now the problem occurs too.

The bug is possibly Linux- or Unix-specific; possibly even GTK3-specific.


Package versions:
 - libreoffice-gtk3: 1:5.2.4-2
 - libgtk-3-0:amd64: 3.22.3-2


Workstation:

Version: 5.2.4.2.1+
Build ID: 1:5.2.4-2
CPU Threads: 8; OS Version: Linux 4.7; UI Render: default; VCL: gtk3; 
Locale: en-US (en_US.utf8); Calc: group


Laptop:

Version: 5.2.4.2.1+
Build ID: 1:5.2.4-2
CPU Threads: 4; OS Version: Linux 4.2; UI Render: default; VCL: gtk3; 
Locale: en-US (en_US.utf8); Calc: group
Comment 4 Octavio Alvarez 2017-01-23 11:13:58 UTC
I'm changing this from NEEDINFO to UNCONFIRMED. Maybe somebody can confirm the occurrence of this bug specifically on GTK 3. I mistakenly set it to NEW before; now it's correctly set to UNCONFIRMED.
Comment 5 Buovjaga 2017-01-25 17:16:25 UTC
Not reproduced.

Arch Linux 64-bit, KDE Plasma 5
Version: 5.4.0.0.alpha0+
Build ID: 63fd4c97118a943c84ba5a666cf8c9cc54b511c7
CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on January 22th 2016
Comment 6 Aron Budea 2017-03-12 18:12:56 UTC
I could reproduce this with a recent master build / Ubuntu 16.10.
Not sure what are the exact requirements, because sometimes it worked, other times it didn't. What seemed to yield the best chances is to move the slide until it shows the little box in its new place, then move the cursor up a bit.

I'll try to create a screencast later.

Version: 5.4.0.0.alpha0+
Build ID: 98a03d9b0d13b8f811ccf8fc1a9b7f9469ed079c
CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); Calc: group
Comment 7 Aron Budea 2017-03-12 22:48:09 UTC
Created attachment 131838 [details]
Screencast with a bunch of attempts

I had to try 7 or so times... the last attempt was successful.
Comment 8 Caolán McNamara 2017-07-25 12:19:22 UTC
Still can't reproduce this in master under gtk3
Comment 9 Octavio Alvarez 2017-07-25 14:55:13 UTC
Just reproduced it again on Debian Sid, LibreOffice 5.4 (taken from the Experimental repo).

Version: 5.4.0.2
Build ID: 1:5.4.0~rc2-1
CPU threads: 4; OS: Linux 4.2; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.utf8); Calc: group

$ dpkg -l | grep libreoffice-gtk
rc  libreoffice-gtk                       1:5.2.5-1                              all          transitional package to upgrade to libreoffice-gtk2/-systray
ii  libreoffice-gtk3                      1:5.4.0~rc2-1                          amd64        office productivity suite -- GTK+ 3 integration

I just uploaded a repro demo to YouTube: https://youtu.be/AbRm-wXEdOs

Are there any UI debu logs we can check? Maybe logs that say "we got this event, mouse moved from here to here, we got a click on this location which translates to this widget". We may need to discriminate if it is GTK3 or LibreOffice that is misbehaving.
Comment 10 Aron Budea 2017-07-25 15:05:57 UTC
(In reply to Octavio Alvarez from comment #9)
> I just uploaded a repro demo to YouTube: https://youtu.be/AbRm-wXEdOs

I could repro using a master build from yesterday (3e4b0bde6252b80ccc99c8b9ae261d79456ba026).
Comment 11 Julien Nabet 2017-07-28 20:40:31 UTC
On pc Debian x86-64 with master sources updated today + gtk3, I could reproduce this.

I noticed this when creating a second slide:
warn:legacy.osl:3400:1:sd/source/ui/accessibility/AccessibleSlideSorterView.cxx:759: OSL_ASSERT: nIndex>=0 && (sal_uInt32)nIndex<maPageObjects.size()

when changing order, I noticed these:
warn:vcl.gdi:3400:1:vcl/headless/svpgdi.cxx:97: unsupported SvpSalGraphics::blendAlphaBitmap case
warn:legacy.osl:3400:1:sal/rtl/string.cxx:202: OSL_ASSERT: nLength == 0 || rtl_isOctetTextEncoding(nEncoding)
warn:legacy.tools:3400:1:editeng/source/items/textitem.cxx:1922: SvxColorItem: Is there a new file format? 
warn:legacy.tools:3400:1:editeng/source/items/textitem.cxx:2778: SvxEmphasisMarkItem: Is there a new file format? 
warn:legacy.tools:3400:1:editeng/source/items/frmitems.cxx:2245: SvxBoxItem: Is there a new file format?
warn:legacy.tools:3400:1:editeng/source/items/textitem.cxx:1922: SvxColorItem: Is there a new file format? 
warn:legacy.osl:3400:1:sd/source/ui/accessibility/AccessibleSlideSorterView.cxx:759: OSL_ASSERT: nIndex>=0 && (sal_uInt32)nIndex<maPageObjects.size()
warn:legacy.osl:3400:1:sd/source/ui/accessibility/AccessibleSlideSorterView.cxx:759: OSL_ASSERT: nIndex>=0 && (sal_uInt32)nIndex<maPageObjects.size()
warn:legacy.osl:3400:1:sd/source/ui/accessibility/AccessibleSlideSorterView.cxx:759: OSL_ASSERT: nIndex>=0 && (sal_uInt32)nIndex<maPageObjects.size()
warn:legacy.tools:3400:1:sd/source/ui/view/drviews1.cxx:622: sd::DrawViewShell::getCurrentPage(), illegal page index!

with ctrl-Z (to repeat the sequence), I got:
warn:legacy.tools:3400:1:sd/source/ui/slidesorter/controller/SlsPageSelector.cxx:84: PageSelector::DeselectAllPages: the selected pages counter is not 0

After less than 10 times, I could reproduce this.
Comment 12 Caolán McNamara 2017-10-18 11:19:44 UTC
bah, this is so frustrating. I can clearly see from the video that it disappears, but it refuses to do this for me locally.

When it disappears, and you visit the undo menu does it say

"Delete Slides"
"Delete slides"
or
"Delete Slide"
Comment 13 Aron Budea 2017-10-18 13:33:57 UTC
It says:

Delete slides
Drag and Drop Slides
...
Drag and Drop Slides
Insert Slide


(I had to try a couple of times, that's why there are several Drag and Drop Slides entries)
Comment 14 Octavio Alvarez 2017-10-18 17:24:49 UTC
For me it is like this:

Set up: I set the title for the only slide, then insert new and edit its title, then insert a third one and edit its title (just to track each down).

So Undo, before the bug, it looks like this (history from newest to oldest, as seen on the GUI):

Edit text of Title text to...
Insert Slide
Edit text of Title text to...
Insert Slide
Edit text of Title text to...

Then I do the dragging. If it works correctly (bug fails to appear) Undo looks like this:

Drag and Drop slides
Edit text of Title text to...
Insert Slide
Edit text of Title text to...
Insert Slide
Edit text of Title text to...

So I do Ctrl+Z and try again (this removes the Drag from Undo). Once it happens, the Undo history looks like this:

Delete slides
Edit text of Title text to...
Insert Slide
Edit text of Title text to...
Insert Slide
Edit text of Title text to...
Comment 15 Octavio Alvarez 2017-10-18 17:28:17 UTC
Caolan, is there a way that I can log/discern if GTK3 is actually sending a Drag event and not a Delete event? IOW, what if GTK3 is at fault, is there a test I can do to find out?

Or is there any other kind of logging we can gather to provide better information to you?

On my computer is reproducible; randomish, but reproducible.
Comment 16 Xisco Faulí 2018-07-19 16:36:28 UTC
I can no longer reproduce it in

Version: 6.2.0.0.alpha0+
Build ID: 934c7fdd23c95858fba022ba1fe7c00d23f502b5
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded

Closing as DUPLICATED of bug 118302

@Octavio, Please give it a try in 6.1.0.2 tomorrow or the day after to doublecheck it's fixed...

*** This bug has been marked as a duplicate of bug 118302 ***
Comment 17 Octavio Alvarez 2018-08-02 00:53:36 UTC
Looks good! I will reopen if it happens again. Thanks!