Bug 35570 - Moving rows (and columns too) in tables overwrites content
Summary: Moving rows (and columns too) in tables overwrites content
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: László Németh
Whiteboard: target:6.5.0 target:
Depends on:
Blocks: Writer-Tables-Enhancements
  Show dependency treegraph
Reported: 2011-03-22 15:38 UTC by mikefreeman1972
Modified: 2020-02-21 19:31 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:

Test case: Rose Dewar's resume template (12.89 KB, application/vnd.oasis.opendocument.text)
2011-11-02 18:19 UTC, Stuart Simon

Note You need to log in before you can comment on or make changes to this bug.
Description mikefreeman1972 2011-03-22 15:38:40 UTC
Now that we have this new project going that is further separated from OpenOffice than GoOO was, I'm going to restate a request I made years ago (and re-emphasized many times in both OOo forums and the bug report).

Does anyone know if we are ever going to see a fix for the bad handling of row moving in tables? I requested this (and made a matching bug report in Sun's OOo forums) many years ago, in the OpenOffice.org 2.x era. After much argument over the necessity for it, the devs finally said that a fix was slated for somewhere in the 3.x releases. It has never come. Here is a description of this bug...

Do this within Writer:

   1. Create a table of more than one row, and as many columns as you like
   2. Enter content into all rows
   3. Highlight one complete row by click-and-dragging the mouse from the first column to the last
   4. Using the mouse, click on that row and drag it to another row

What happens: the contents of the row you want to move overwrite the contents of the row you move it to and leave a blank row where you moved it from.

What is expected: the row you move should be inserted at the location you drag it to, while all rows between the two locations should be moved up or down, depending on where you are moving from, so that all information is still intact, and no blank rows are left.

Why this is expected: First, it is the common usage on most other word processing programs. Second, it is common for any drag and drop moving of content to be in insert mode rather than overwrite mode. In otherwords, you wouldn't want to highlight a sentence in a paragraph, drag it to a new location in the paragraph, and have it overwrite the sentence(s) in the location you drag it to, right? No, the content in between the two locations is moved to make room for the sentence. The same should be true on any similar move, including within a table.

Current workaround: You have to manually insert a new row in the location you want to move the content to, highlight and drag the content to the new blank row, then delete the newly-created empty row. 3x the amount of work as is necessary.
Comment 1 Stuart Simon 2011-11-02 18:19:54 UTC
Created attachment 53093 [details]
Test case: Rose Dewar's resume template

I would like to provide an example where this could be useful. Of the four templates included in LibreOffice for resumes in US English, the fourth one, by Rose Dewar, is closest to what I want. However, both my university's Web site and another site recommend placing "Education" before "Professional Experience." The problem is that Dewar's template is based on an invisible table, and since the headings are in the table, dragging and dropping around the Navigator is not an option. The ability to just drag and drop rows would make this quite easy.
Comment 2 Stuart Simon 2011-11-02 18:24:47 UTC
I want to add that this is the default behavior on most word processors, including MS Word.
Comment 3 Björn Michaelsen 2011-12-23 11:52:22 UTC Comment hidden (obsolete)
Comment 4 sasha.libreoffice 2012-01-23 08:25:45 UTC
reproduced in LibO master from 23 jan 2012 on Fedora 64 bit
Comment 5 mikefreeman1972 2012-01-23 12:09:22 UTC
I can confirm that this is still an issue with the latest release candidate as of January 23, 2012.
Comment 6 mikefreeman1972 2012-05-03 10:42:30 UTC
This problem still exists as of the latest 3.5.3 release (May 2, 2012). Is there any intention of fixing this bug? Just like when moving any other elements in a document, insert should always be the default case, not overwrite.
Comment 7 sasha.libreoffice 2012-05-03 22:11:12 UTC
Intention of fixing exist. But currently not enough resources. Sorry for such situation.
Comment 8 Michael Meeks 2012-05-04 02:02:24 UTC
Gosh; it'd be nice to fix of course - but I imagine, while un-expected, it is not such a debilitating bug that it can't be learned and worked around.

Of course, I'd love a fix - if you want to get involved in hacking on it you're most welcome.


Is prolly a good place to read around - the mouse down / up methods etc.

Comment 9 sasha.libreoffice 2012-05-04 02:31:18 UTC
Thanks for code point. It is very useful for fixing problems with table editing
Comment 10 mikefreeman1972 2013-04-02 23:00:35 UTC
Also exists in
Comment 11 sasha.libreoffice 2013-04-03 10:02:48 UTC
Thanks for additional testing.
Sorry, but "Version" is where bug supposed appears. Not a current version of LO. If bug fixed, we just closing bug.
Changing back to 3.5.3
Comment 12 Paddy Landau 2013-05-23 09:43:58 UTC
The bug is still present in version and prior.

May I change the version number accordingly?
Comment 13 Paddy Landau 2013-05-23 10:00:18 UTC
I have also added bug #64902 because it is virtually the same as this one, but involves columns instead of rows.
Comment 14 Cor Nouws 2013-05-23 10:44:48 UTC
*** Bug 64902 has been marked as a duplicate of this bug. ***
Comment 15 Cor Nouws 2013-05-23 10:51:04 UTC
Hi guys & girls,

It makes no sense to write every release that this has not been changed.
As long as it is not marked as such, it is not changed.

Set this to the oldest version available - it is like this since the early days of OOo. Note that this behaviour in Calc was only changed some few (3, 4?) years ago.

Also I am tempted to set this to enhancement :)
It would be best of course, if there was some popup asking if you wuld like to insert or overwrite.
Comment 16 Paddy Landau 2013-05-23 10:55:15 UTC
Cor: "It would be best of course, if there was some popup asking if you wuld like to insert or overwrite."

I humbly disagree. When you drag with the cursor, it points to a specific location, which is standard (always) to mean an insert, not an overwrite. I know of no text editor that behaves differently.
Comment 17 mikefreeman1972 2013-05-23 22:18:46 UTC

You're welcome to change this to "enhancement" or whatever you wish, as long as it gets this issue fixed faster. I've been waiting for this for many years (since the OOo 2.0 days), and was promised from the OOo people, since before everything blew up and LibreOffice fork was made, that it would definitely be done in the 3.x series. I do understand, though, that this fork is by a different group and any promises by one is not bound to the other.

As for the popup recommendation, I would imagine that would be the worst way to do it (no offense). Would you want a popup every time you went to move a section of a paragraph or an image? Of course not. You just want it to be inserted into the spot you dragged it to. Anything else (including the current table behavior) is just non-intuitive design, causing unnecessary extra work for the user.

As for making comments about the version it affects, I do this for two reasons:

1. Because I guess I misunderstood that "Version" means the first version it affected, not the most recent version it affects. That's sort of vague and should maybe be clarified.

2. To see if anyone is actually paying attention. Squeaky wheel sort of thing.

Thank you for your comments, though. I do appreciate it!
Comment 18 Cor Nouws 2013-05-24 11:52:12 UTC
HI paddy & mike
thanks for your both comments.

Hmmm. well .. I only can say: yes that I agree that changing the behaviour is a good thing.
(mind that of course I've basically no influence on that, apart from trying to help development a bit by providing properly handled bug reports and growing the project in general ;) )
Comment 19 Jim Avera 2014-01-13 19:10:40 UTC
Bump.  Still aggrivated at this in   Any progress?

For years this has been a productivity-reducer for me; I'll echo previous commenters that, for me, the current behavior is never helpful and always harmful.
Comment 20 Paddy Landau 2014-01-13 19:41:29 UTC
I'm using Alas, the problem is still here.

The cursor changes to a pointer that implies there will be an insert, not an overwrite, so it's always a bit of a shock even though I now expect it.

It's an unfortunate bug relic for a mature application.
Comment 21 mikefreeman1972 2014-10-30 21:00:30 UTC
We're at Libreoffice, and this frustrating annoyance is STILL there? I know you guys aren't the original Sun Microsystems people, but I was told by one of their developer way back at OOo 2.x that this bug was planned to be fixed in the 3.x cycle. Many, many, MANY years later, and many years beyond the beginning of the 3.x cycle, and we're still discussing the problem. Does anyone know if this is even being noticed by anyone on the dev team?
Comment 22 Michael Meeks 2014-10-30 21:34:40 UTC
Hi Mike,

> I know you guys aren't the original Sun Microsystems people

Right - they went bust because they didn't build an ecosystem of people that supported development: either by contributing code, or by funding others to do that. As you say, it is years later - and I'm wondering why you're not contributing to fix this yourself =) It is clear that you personally are not fixing it just as much as any member of the development team is not fixing it.

Please do get involved; propose a patch, dig into the code etc. The frequent riposte to this is "but I'm not 'a developer'" - guess what, that's how everyone starts out contributing =) every developer you see today, was once - not one; if you're willing to learn, I'm willing to help you.

All the best,

Comment 23 Paddy Landau 2014-10-31 15:12:08 UTC
Alas, the problem is still present in version 4.4 (alpha).

@Micheal Meeks, I hear what you say. As a non-programmer, I've contributed to open-source software in other ways (e.g. user help and documentation). However, this is one area where I am completely unable to help — we users depend on the programmers for this.

This bug already seems to have a high priority. Could it be raised to the developers for inclusion? It is an important "paper cut" from the user's point of view.
Comment 24 Renato Ferreira 2014-11-26 04:18:41 UTC
I've just tested this behaviour in Apple's Pages and it's the same thing, moving a table row replaces the content and leaves the original one blank. Even in regular spreadsheets that happens, unless you drag the entire row of the spreadsheet, in which case you get the option to move that thing to in between two other rows.

In light of that, I'd say that a design choice should come before technical efforts anyway.
Comment 25 Cor Nouws 2014-11-26 16:02:18 UTC
enough arguments to mark this as enhancement
Comment 26 mikefreeman1972 2015-08-10 20:49:01 UTC
It's now 2015, and LibreOffice 5.0 still has this bug. I've been repeatedly asking for this for nearly 10 years, since OpenOffice 2.0, and nothing's changed. Back then, I was told by the Sun Microsystems devs that the problem would be fixed sometime in OpenOffice 3.x. Then the big upheaval happened, and that the bug went unfixed in either OpenOffice or this LibreOffice fork. Should I have any hope at this point of this ever getting fixed?
Comment 27 Cor Nouws 2015-08-10 20:59:42 UTC

It's free software: anyone is allowed to contribute or to hire/find others to do so. And as you see with all the improvements over the past 4 years, it works.
So there is hope :)
Comment 28 Xisco Faulí 2019-11-29 13:29:44 UTC
Changing priority back to 'medium' since the number of duplicates is lower than 5
Comment 29 László Németh 2019-12-16 20:25:37 UTC
I have reopened Bug 64902 for solving this problem by new menu options, like in MSO, as also suggested in https://bz.apache.org/ooo/show_bug.cgi?id=13645#c2
Comment 30 László Németh 2019-12-18 10:56:28 UTC
Proposed solution: https://gerrit.libreoffice.org/#/c/85375/
Comment 31 László Németh 2019-12-18 18:57:46 UTC
tdf#35570 Writer: drag and drop rows/columns without overwriting

cells of the target table. Instead, paste rows above or
columns before in the case of enhanced table selection
(clicking in front of the copied rows or columns) or in
the case of wholly selected tables.

At moving (without pressing Ctrl during drag and drop),
remove the originally selected rows or columns instead
of emptying them.
Comment 32 Commit Notification 2019-12-18 18:58:26 UTC
László Németh committed a patch related to this issue.
It has been pushed to "master":


tdf#35570 Writer: drag and drop rows/columns without overwriting

It will be available in 6.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:

Affected users are encouraged to test the fix and report feedback.
Comment 33 Commit Notification 2019-12-19 11:26:10 UTC
László Németh committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":


tdf#35570 Writer: drag and drop rows/columns without overwriting

It will be available in

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:

Affected users are encouraged to test the fix and report feedback.