Bug 32026 - TABLES: Writer loses cells' content after drag-and-drop
Summary: TABLES: Writer loses cells' content after drag-and-drop
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: Other All
: high critical
Assignee: Not Assigned
: 51226 (view as bug list)
Depends on:
Blocks: Writer-Tables
  Show dependency treegraph
Reported: 2010-12-01 13:06 UTC by Aspide
Modified: 2018-10-08 12:30 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:

New test document a table witha few rows (10.49 KB, application/vnd.oasis.opendocument.text)
2015-06-26 09:37 UTC, Marc Kaulisch
Test document after drag&drop (10.35 KB, application/vnd.oasis.opendocument.text)
2015-06-26 09:38 UTC, Marc Kaulisch

Note You need to log in before you can comment on or make changes to this bug.
Description Aspide 2010-12-01 13:06:49 UTC
Say I have a table (1 col x 5 rows).
I select 3 cells (rows 2-4).

If I drag the selection one row up (for cells' content to fit rows 1-3), only the first (former second) row's content is retained, the others' is lost.

If I try to drag the selection one row down (to rows 3-5), Writer doesn't allow me to do so.

Tables with more columns behave the same way.

If I drag several cells' content to a new place, but next I undo (ctrl-z) the action, selection restores not to cells that were selected before, but to their contents only. So next drag operation will merge the contents from different cells into one.
Comment 1 ubhh11 2011-06-18 08:01:31 UTC
The problem still exists in 3.3.2.
Comment 2 Jeffrey 2011-06-20 19:32:16 UTC
I managed to reproduce this bug on LibreOffice 3.4  340m1(Build:12) on OpenSuse. Here is the scenario: A 1 col by 7 row table with entries in the rows 3 - 7. If you drag and drop entries 3 - 7 to row 1, only entries from 3 and 4 remain in rows 1 and 2. What seems to be happening is that only the rows outside the bounds of the data previously highlighted (in this case 3 - 7) will be successfully dragged and dropped.

Row Data
3   a
4   b
5   c
6   d
7   e

Drag and drop all data to row 1:

1   a
2   b

This seems to always be the case. If I dragged all entries to row 2, then only data "a" will show up in row 2, and all other rows will be empty. You can drag selections down, but Writer does not allow you to drag to any of the highlighted rows. So for:

Row Data
1   q
2   z
3   a
4   b

I can only drag the four entries to row 5 or greater. If I do, Writer will automatically allocate extra space:

Drag and drop all data to row 5:

5   q
6   z
7   a
8   b

So it looks like the problem of drag and drop within the tables of writer moving up or down are exactly the same: You cannot drag entries to the currently highlighted cells, and only those outside the regions of the highlighted cells will show up.
Comment 3 Urmas 2013-01-24 12:25:20 UTC
Moving back to New after two year hiatus.
Comment 4 Zeki Bildirici 2014-01-18 21:48:38 UTC
(In reply to comment #3)
> Moving back to New after two year hiatus.


Still reproducable in Version:
Build ID: 420m0(Build:1).

- Only two rows can be moved and deletes the content in the target cells.
- If you drag one cells content, it does not delete the target cell, it adds the content.

Best regards,
Comment 5 QA Administrators 2014-10-23 17:31:44 UTC Comment hidden (obsolete)
Comment 6 Marc Kaulisch 2015-06-26 09:11:39 UTC
I am not sure if I have the same problem than described here, but it looks similar.
I am using 
Version: (x64)
Build-ID: 9a0b23dd0ab9652e0965484934309f2d49a7758e
Gebietsschema: de-DE (de_DE)

When I want to move two rows of a table to the empty row above the two rows only the first row is moved, the second row is missing/deleted/not appearing...

I think this is a severe problem IMHO
Comment 7 Marc Kaulisch 2015-06-26 09:37:29 UTC
Created attachment 116837 [details]
New test document a table witha few rows
Comment 8 Marc Kaulisch 2015-06-26 09:38:19 UTC
Created attachment 116838 [details]
Test document after drag&drop

these documents are created with on Windows
Comment 9 Marc Kaulisch 2015-06-26 09:39:56 UTC
I can reproduce the problem also with on Windows

Moving rows 3. and 4. one row up results in row 3. is moved and 4. is deleted/disappears...

Loss of information that is severe, or?
Comment 10 Buovjaga 2015-06-26 10:13:15 UTC
Yep still repro the steps in description.

Win 7 Pro 64-bit Version: (x64)
Build ID: a51ac4d2bb8c4f1ea1d4ea7569863e2fb6535b02
TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2015-06-22_21:37:53
Locale: fi-FI (fi_FI)
Comment 11 Buovjaga 2015-06-26 10:21:33 UTC
*** Bug 51226 has been marked as a duplicate of this bug. ***
Comment 12 Marc Kaulisch 2015-07-26 15:39:26 UTC
I can still reproduce this bug in 64bit on Win8.1

I push importance to blocker because information is lost.
Comment 13 Timur 2015-07-27 13:13:11 UTC
According to https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg, it was correctly marked as High-Critical.
While it's a pity it's still open, overmarking will not help.
Comment 14 Marc Kaulisch 2015-08-14 13:23:06 UTC Comment hidden (obsolete)
Comment 15 tommy27 2015-08-26 13:06:33 UTC
I tested under Win8.1 x64 and the issue is still there in and

Build ID: 7d3fa6bae9f7a755eb2d0ca24bf1afd5f3646bb7
TinderBox: Win-x86@39, Branch:master, Time: 2015-08-09_08:38:08
Locale: it-IT (it_IT)

however my 5.1 alpha build is not up to date and I cannot exclude it's fixed in 5.0.1 rc2
Comment 16 rbruenner 2016-04-29 11:22:02 UTC
I can confirm that the problem with LO 5.1.2 on Mac OS X 10.10.5 still exists.
Comment 17 Telesto 2017-01-26 19:34:20 UTC
Still a repro with:
Build ID: 79497f458727a0dea983847fe9d3873bf9c2e972
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-01-24_03:10:09
Locale: nl-NL (nl_NL); Calc: CL
Comment 18 Michael Stahl (allotropia) 2017-11-23 12:30:40 UTC
"steve__" was just asking about this; i'd start debugging in SwTransferable::PasteData() which should be the start of the "drop" operation;
possibly it's another of the SwTransferable functions, 
SwTransferable::PrivateDrop() maybe.
Comment 19 Michael Stahl (allotropia) 2017-11-23 13:15:22 UTC
steve__, just use git grep:

git grep SwTransferable::PasteData
sw/source/uibase/dochdl/swdtflvr.cxx:bool SwTransferable::PasteData( TransferableDataHelper& rData,
Comment 20 Christian Pietzsch 2018-10-07 01:49:40 UTC
I tested this Bug in:
Build ID: 6.1.0-2
CPU threads: 12; OS: Linux 4.18; UI render: default; VCL: gtk2; 
Locale: de-DE (en_US.UTF-8); Calc: group threaded

I couldn't reproduce it. Content of all dragged rows/columns gets moved to the new cells.

The only thing I can reproduce is that you move cells to a space that you have marked for moving. For example you can't move row 2-4 to row 3-5. You can only move to 5-7.

But I think the main problem (content disappearing) is fixed in LO 6.1.
Comment 21 Timur 2018-10-08 12:30:22 UTC
Repro with 5.4.7, no repro with 6.0.6 and 6.2+.