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
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?
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
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
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.
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
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
Created attachment 131838 [details] Screencast with a bunch of attempts I had to try 7 or so times... the last attempt was successful.
Still can't reproduce this in master under gtk3
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.
(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).
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.
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"
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)
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...
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.
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 ***
Looks good! I will reopen if it happens again. Thanks!