Bug Hunting Session
Bug 72075 - EDITING: undo leads to duplication for operations that involve of drag-and-drop (Slide pane, text areas)
Summary: EDITING: undo leads to duplication for operations that involve of drag-and-dr...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
(earliest affected) release
Hardware: Other All
: highest normal
Assignee: Caolán McNamara
Whiteboard: target:5.2.0
Keywords: bibisected, bisected, regression
Depends on:
Reported: 2013-11-27 15:00 UTC by Jérôme Borme
Modified: 2016-10-25 19:02 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

testcase (11.32 KB, application/vnd.oasis.opendocument.presentation)
2014-12-08 10:00 UTC, tommy27

Note You need to log in before you can comment on or make changes to this bug.
Description Jérôme Borme 2013-11-27 15:00:06 UTC
Steps to reproduce:
1. Create or open a presentation with several slides
2. Using the Slide pane, move (drag and drop) a slide to another place in the presentation
3. Use Edit/Undo

Expected result: the slide should *move back* to its initial place.
Actual result: the slide is *copied* to its initial place.
Comment 1 Jérôme Borme 2013-12-01 17:13:41 UTC
Similar bug with text boxes (I updated the title for a more general formulation).

1. Create a text area with some text inside.
2. Select some text and drag-and-drop it outside the area. At this point LibO automatically created another text area top contain the pasted text.
3. Edit/Undo.

Result: the text is indeed restored inside the original text area but the new text area which was automatically created by the drag-and-drop operation was not removed (it should have been removed).
Comment 2 Mihkel Tõnnov 2013-12-20 22:15:31 UTC
Confirmed with on Debian x86.
Comment 3 Björn Michaelsen 2014-01-17 09:51:43 UTC Comment hidden (obsolete)
Comment 4 tommy27 2014-05-13 05:30:09 UTC
please retest against
if bug persists please move it to mab4.2 list since 4.1.x is EOL
Comment 5 Jérôme Borme 2014-05-13 08:11:50 UTC
Right now I can test with and the bug persists, but I now noticed if you press a second time Edit/Undo then the action is properly undone. Which means 1) there is a workaround! 2) the bug can be reformulated as: one extra action gets inserted in the history, so the user needs a double undo to get read of it.

I can't test right now with but only (still it's a 4.2.x) so I'll test again when the version you were asking for becomes available in my distribution.
Comment 6 tommy27 2014-05-13 08:45:01 UTC
in the meantime I move it to mab4.2 list
close it if it works in (but I think that's unlikely)
Comment 7 tommy27 2014-12-08 10:00:17 UTC
Created attachment 110562 [details]

bug confirmed under Win8.1 64bit using LibO and alpha

load the attached test case.
move slide 1 after slide 3, then click edit/undo.

moving this to mab4.3 list since 4.2.x is end of life
Comment 8 tommy27 2014-12-08 10:03:12 UTC
works fine in LO 
bug present in
nece this is a 4.0.x brach regression, needs bibisecting
Comment 9 Matthew Francis 2014-12-09 10:45:41 UTC
Bibisect results from 43all:

3d8d766f50d0fd4ead4d4f7074a35bba465b365c is the first bad commit
commit 3d8d766f50d0fd4ead4d4f7074a35bba465b365c
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Tue Dec 11 08:13:31 2012 +0000

    commit b67a51b40a4876f4bd97a2917103112006710b0c
    Author:     Markus Maier <maier@fs.ei.tum.de>
    AuthorDate: Thu Nov 29 16:10:23 2012 +0000
    Commit:     Caolán McNamara <caolanm@redhat.com>
    CommitDate: Thu Nov 29 17:35:25 2012 +0000
        add sort tab page .ui
        Change-Id: Ib5471b2a4cae45cf8aa32b438bac7f5cda35f71a

# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [cf86b7f14a98d2d81a5cd93507acb35ff6775d8b] source-hash-85c6244b85b29c1d2bb9d89b62e9512dd65378b5
git bisect start 'latest' 'last35onmaster'
# bad: [34eab3946c46bb7273ba4ca395db9c4421dd232f] source-hash-e962805b31074d6b6a2ed0db6452769448337553
git bisect bad 34eab3946c46bb7273ba4ca395db9c4421dd232f
# good: [2e2d1aeff80dcbe390f6c3fbc54d6c8de81b0a0e] source-hash-64ab96cd15e52da88781e720d6f031dbcd0ba902
git bisect good 2e2d1aeff80dcbe390f6c3fbc54d6c8de81b0a0e
# bad: [9ac72638fdc1adf45f17c71f66baf9b20b606891] source-hash-1ed4210d8e6cbf1b25cd1eb8666be6578cc45845
git bisect bad 9ac72638fdc1adf45f17c71f66baf9b20b606891
# bad: [f0250a5564d9cdd406d788062cff81319971ccae] source-hash-db99a31c4e4e7c74d4c4bb7caa747a5752a32757
git bisect bad f0250a5564d9cdd406d788062cff81319971ccae
# good: [5809284e8a6f97fe3b5beb037b6b80eeb9fe1058] source-hash-246ffb108c7e1f762f8d497750ad2414b85b99ef
git bisect good 5809284e8a6f97fe3b5beb037b6b80eeb9fe1058
# bad: [4ef3a89e32ccba70e4b194ad97d110b88ce41c72] source-hash-8450a99c744e9005f19173e4df35d65640bcf5c4
git bisect bad 4ef3a89e32ccba70e4b194ad97d110b88ce41c72
# bad: [3d8d766f50d0fd4ead4d4f7074a35bba465b365c] source-hash-b67a51b40a4876f4bd97a2917103112006710b0c
git bisect bad 3d8d766f50d0fd4ead4d4f7074a35bba465b365c
# good: [f8b7f4b27eb8b3df4259a6d986607fd414f552af] source-hash-9d83ad0e99ab182506be99f7d6a2bec7f6fbe8c6
git bisect good f8b7f4b27eb8b3df4259a6d986607fd414f552af
# good: [e262cafc6f2ef071a248432b4d850e49d9e68c66] source-hash-c33019b36d613f951787ce9836e34d74bfbd6a1b
git bisect good e262cafc6f2ef071a248432b4d850e49d9e68c66
# first bad commit: [3d8d766f50d0fd4ead4d4f7074a35bba465b365c] source-hash-b67a51b40a4876f4bd97a2917103112006710b0c
Comment 10 Matthew Francis 2014-12-09 10:51:58 UTC
It's not immediately obvious which commit in the above range could be at fault, and the regression is too old to conveniently build
Comment 11 Matthew Francis 2015-01-09 09:34:09 UTC
There issue first appears in the range cbb599f657acc1953ef77d4f4fd895f75f9c7dad..22e54a9d0ee80b156ddb74a3d80330d48213ce9e, where there is some build breakage, but it seems probable that commit cbb599f657acc1953ef77d4f4fd895f75f9c7dad is the main issue here

commit 22e54a9d0ee80b156ddb74a3d80330d48213ce9e
Author: Andre Fische <andre.f.fischer Andre Fischerandre.f.fischer@oracle.com>
Date:   Fri Mar 11 15:22:17 2011 +0100

    impress211: #i110990# Fixed remaining problems with display ids and indices.

commit 5c3614639cc448e5bdab6ed303de26a5ef9ce894
Author: Philipp Lohmann [pl] <Philipp.Lohmann@Oracle.COM>
Date:   Wed Mar 9 13:57:56 2011 +0100

    impress211: fix a warning

commit a46904855c32c306f42fce76735045d82013d993
Author: Philipp Lohmann [pl] <Philipp.Lohmann@Oracle.COM>
Date:   Wed Mar 9 13:50:30 2011 +0100

    impress211: fix a warning

commit 9177901fd6491be2937126839e5b96b1bb77ae7c
Author: Philipp Lohmann [pl] <Philipp.Lohmann@Oracle.COM>
Date:   Wed Mar 9 13:46:28 2011 +0100

    impress211: fix some warnings, types

commit 8bcf6ba5586818f4100113a6b685e891de84a5ea
Author: Andre Fische <andre.f.fischer Andre Fischerandre.f.fischer@oracle.com>
Date:   Wed Mar 9 11:16:39 2011 +0100

    impress211: #i110990# Fixed slide show spanning multiple displays on Windows.

commit cbb599f657acc1953ef77d4f4fd895f75f9c7dad
Author: Andre Fische <andre.f.fischer Andre Fischerandre.f.fischer@oracle.com>
Date:   Tue Mar 8 17:22:13 2011 +0100

    impress211: #i88880# Fixed dragging of slides from navigator to slide sorter.
Comment 12 Matthew Francis 2015-01-09 09:35:56 UTC
("The issue..." - I need to typemo re carefully)
Comment 13 Robinson Tryon (qubit) 2015-12-13 11:09:19 UTC Comment hidden (obsolete)