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.
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.
I want to add that this is the default behavior on most word processors, including MS Word.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
reproduced in LibO master from 23 jan 2012 on Fedora 64 bit
I can confirm that this is still an issue with the latest release candidate as of January 23, 2012.
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.
Intention of fixing exist. But currently not enough resources. Sorry for such situation.
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. http://cgit.freedesktop.org/libreoffice/core/tree/sw/source/ui/docvw/edtwin.cxx#n3922 Is prolly a good place to read around - the mouse down / up methods etc. HTH.
Thanks for code point. It is very useful for fixing problems with table editing
Also exists in 4.0.2.1rc.
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
The bug is still present in version 4.0.3.3 and prior. May I change the version number accordingly?
I have also added bug #64902 because it is virtually the same as this one, but involves columns instead of rows.
*** Bug 64902 has been marked as a duplicate of this bug. ***
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.
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.
Cor: 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!
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 ;) )
Bump. Still aggrivated at this in 4.2.0.1 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.
I'm using 4.1.4.2. 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.
We're at Libreoffice 4.3.3.2, 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?
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, Michael.
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.
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.
enough arguments to mark this as enhancement
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?
@mike, 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 :) Cheers, Cor
Changing priority back to 'medium' since the number of duplicates is lower than 5
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
Proposed solution: https://gerrit.libreoffice.org/#/c/85375/
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.
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4ea1f7363d68296219f371076a93d3e480289368 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: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
László Németh committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/20d91d5f45f3d1429dd64ad27469368f36f5fe5e tdf#35570 Writer: drag and drop rows/columns without overwriting It will be available in 6.4.0.2. 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: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.