Dragging and dropping a table leaves a empty table behind. How to reproduce: Create a new writer document. Insert a table 3 by 2. Type in the numbers 1 to 6 in the table with one number in each cell. Click on Insert -> Header -> Default. Highlight all 6 cells then drag & drop the cells to the header. What happens: It creates a new table in the header and moves the data from the old table to the new one but it does not delete the now empty table in the body of the document. What should happen: It should move the table & contents to the header without leaving anything behind. This bug happens whatever part of your document you move a table to.
three people have reproduce this bug on: Gentoo Libreoffice version 3.4.3 Debian (squeeze-backports) Libreoffice version 3.3.3 Windows 7 Libreoffice 3.4.3
I can confirm the effect, but is it a bug or a feature? a) If you have a table as you described: 1 2 3 4 5 6 b) Select cells 1 and 2 c) Drag to cell with 5 What would you expect c1: nested new table with 2 cells 1 2 in old cell with 5 imho would meet with your expectations c2: cell contents 1 2 replaces cell content 5 6 meets with my expectations and imho current drag behavior for all table @WineLauncher.Jonathan@gmail.com: Can you cite some help or documentation that suggests a behavior differing from the observed one?
I am talking about moving a whole table to area that has no table not about moving cells in a table. As you can see it leaves an empty table. +----+----+----+ | | | | +----+----+----+ | | | | +----+----+----+ Two new lines here +----+----+----+ | 1 | 2 | 3 | +----+----+----+ | 4 | 5 | 6 | +----+----+----+
@WineLauncher.Jonathan@gmail.com Believe me, I exactly know what you observed. I asked you why you expect something different. Can you cite any specifecation, help, documentation underpinning your expectation?
The behaviour is correct if you have certain cells selected. However, if the whole table is selected, you expect to move (not copy) the whole table. This is what happens if you have the table *and* text outside the table selected. The whole table is moved. This should also happen when the whole table (nothing more or less) is selected. Perhaps the problem is that LibreOffice doesn't distinguish between "all the cells" and "the whole table".
> Perhaps the problem is that LibreOffice doesn't distinguish between "all the > cells" and "the whole table". Yes, that exactly seems to be the point. I will think about that some days (other reports, Mailing lists, did I see any similar requests, ...) and check how an enhancement request could have prospect of success
Rainer Bielefeld has reproduce the bug. so I'm adding CONFIRMED to the whiteboard.
@WineLauncher: That's wrong! CONFIRMED does not mean that someone also has seen the effect, but that it has been indicated as something that has that has to be fixed, information is complete. <http://wiki.documentfoundation.org/BugReport_Details#Whiteboard>
There is documentation right in the Gui. Reproduce the bug, then hit the "edit" menu and you will see "undo move: multiple selection". Note that it says move, not copy. Try selecting the table plus at least one other line. Now drag it, and the table will be moved, not copied. Check the edit menu, and it will have recorded that manoeuvre as "move:paragraph" This is inconsistent behaviour, and inconsistent behaviour is a bug. If you wish to argue otherwise, triage is not the place.
I can't see any relevance or reporter's move/copy explications. The explications with "drag/drop table + additional line" is not relevant for the problem of the report, because it describes a paragraph operation (reporter also recognized that), what is something completely different. In LibO WRITER GUIDE - Word Processing with LibreOffice 3.3 - Chapter 9 "Working with Tables" under "Moving a table - Step 3" its explicitly said for "Control+X": "This step removes the contents of the cells but leaves the empty cells, which must be removed in step 6." <cntrl+x> / <cntrl+v> is a very similar operation to 'drag and drop' (or even the same), so that I would expect similar (or the same) behavior and results. My conclusion: -------------- Everything works as intended, reporter did not contribute a well founded reason why the intention should be wrong. So not a bug. I agree with reporter's opinion that for the special intention "move complete Tabel (Contents!)" the result seems a little worrying, but it's consistent to the current table concept, and a modification has to be integrated (or added fixing exactly) to the current concept. Currently I can't see such a concept enhancement, and to be honest, I do not see necessity. @WineLauncher It's without interest what someone who did not read the manual expects. Instead of such expectations conclusive concepts are required. Please feel free to submit an enhancement request if you can provide a conclusive concept. And IMHO you should gain some experience before you start with instructions.
This is inconsistent with a MOVE operation for any other object and should be fixed. It is also inconsistent with the same operation in ANY other word processor on ANY OS. If you MOVE an object it is not supposed to leave any part behind.
It is so frustrating having to justify this as a bug, but here we go... @Rainer Bielefeld Accordingly to your citation, besides being counter-intuitive, cumbersome, impractical, inconsistent,... the procedure of moving a table as described in the manual contains a bug. No other object requires this treatment for being manipulated (hence, inconsistency). In fact, when cutting and pasting a table selected, the cells are left behind and not properly moved. As far as I can tell, the cells *are* part of the table itself, so when cutting the selection these are apparently treated separately from the object they belong to. The same thing happening with a text selection (i.e.: "when cutting/pasting text, only alphanumeric characters are included, punctuation must be removed in step X") would look really weird, no matter in which step they are removed, eventually. If there would be any usability/logic reasons why a table object should be treated differently than any other object, then this bug should be closed. Mind that: usability/logic reasons, not documentation ones. The manual describes only a procedure that works with the current code, and infamous step 6 is a workaround for the bug. Although, since a cut/paste operation does not seem to be able to grab correctly all the components of an object without leaving leftovers, it must be fixed (and the manual updated). (I can't see why this wouldn't be an improvement compared to the current procedure)
going to mark this one as dup of bug 84806 The latter has IMO more practical info *** This bug has been marked as a duplicate of bug 84806 ***