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.
The problem still exists in 3.3.2.
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 1 2 3 a 4 b 5 c 6 d 7 e Drag and drop all data to row 1: 1 a 2 b 3 4 5 6 7 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 5 6 7 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: 1 2 3 4 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.
Moving back to New after two year hiatus.
(In reply to comment #3) > Moving back to New after two year hiatus. Hi Still reproducable in Version: 4.2.0.1 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, Zeki
Please read this message in its entirety before responding. Your bug was confirmed at least 1 year ago and has not had any activity on it for over a year. Your bug is still set to NEW which means that it is open and confirmed. It would be nice to have the bug confirmed on a newer version than the version reported in the original report to know that the bug is still present -- sometimes a bug is inadvertently fixed over time and just never closed. If you have time please do the following: 1) Test to see if the bug is still present on a currently supported version of LibreOffice (preferably 4.2 or newer). 2) If it is present please leave a comment telling us what version of LibreOffice and your operating system. 3) If it is NOT present please set the bug to RESOLVED-WORKSFORME and leave a short comment telling us your version and Operating System Please DO NOT 1) Update the version field 2) Reply via email (please reply directly on the bug tracker) 3) Set the bug to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link: https://wiki.documentfoundation.org/QA/BugTriage There are also other ways to get involved including with marketing, UX, documentation, and of course developing - http://www.libreoffice.org/get-help/mailing-lists/. Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
I am not sure if I have the same problem than described here, but it looks similar. I am using Version: 5.0.0.1 (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
Created attachment 116837 [details] New test document a table witha few rows
Created attachment 116838 [details] Test document after drag&drop these documents are created with 4.4.4.3 on Windows
I can reproduce the problem also with 4.4.4.3 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?
Yep still repro the steps in description. Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ (x64) Build ID: a51ac4d2bb8c4f1ea1d4ea7569863e2fb6535b02 TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2015-06-22_21:37:53 Locale: fi-FI (fi_FI)
*** Bug 51226 has been marked as a duplicate of this bug. ***
I can still reproduce this bug in 5.0.0.4 64bit on Win8.1 I push importance to blocker because information is lost.
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.
can someone confirm that this problem is solved in 5.0.1.1? I cannot reproduce the problem anymore in my 5.0.1.1 64bit version on Win10.
I tested under Win8.1 x64 and the issue is still there in 5.0.0.4 and 5.1.0.0.alpha1+ 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
I can confirm that the problem with LO 5.1.2 on Mac OS X 10.10.5 still exists.
Still a repro with: Version: 5.4.0.0.alpha0+ 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
"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.
steve__, just use git grep: git grep SwTransferable::PasteData sw/source/uibase/dochdl/swdtflvr.cxx:bool SwTransferable::PasteData( TransferableDataHelper& rData,
I tested this Bug in: Version: 6.1.0.3 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.
Repro with 5.4.7, no repro with 6.0.6 and 6.2+.