Bug Hunting Session
Bug 46230 - EDITING: impossible to perform a drag & drop of entire row/column
Summary: EDITING: impossible to perform a drag & drop of entire row/column
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.5.0 release
Hardware: Other All
: high major
Assignee: Markus Mohrhard
URL:
Whiteboard: BSA target:3.6.0 target:3.5.2
Keywords: regression
: 45868 47017 47096 48006 48128 (view as bug list)
Depends on:
Blocks: mab3.5
  Show dependency treegraph
 
Reported: 2012-02-17 06:44 UTC by Helping Hand
Modified: 2012-07-01 10:56 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
Simple Sample (7.16 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-03-12 11:33 UTC, Rainer Bielefeld Retired
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Helping Hand 2012-02-17 06:44:13 UTC
Problem description: 
Impossible to perform a drag & drop of entire row/column, whether moving, copying (+ctrl) or switching (+alt)

Steps to reproduce:
1. Select entire column or row
2. Drag & drop the row / column to be inserted into the new position. If you want to copy or switch simultaneously pressing the ctrl or alt button 

To be less confusing in the descriptions I only use rows, although the same goes for columns, nor will I mention the +ctrl and +alt options although they are affected the same way

Current behavior:
Calc only moves part of the row, starting at the first not empty cell to the last not empty cell, leaving the rest unchanged.

If the first not empty cell is not the first of the row it will be put in the first cell of the new position. e.g. I want to move row 10 to row 2. Row 10 has data in the cells D10, E10 & G10. When I move the entire row 10 to row 2, it results in only moving the cells (D10..G10) to (A2..D2) leaving the rest of row 2 untouched.
 
Expected behavior:
If the entire row is selected, the entire row should be moved

Platform (if different from the browser): 
              
Browser: Mozilla/5.0 (Windows NT 6.0; rv:10.0) Gecko/20100101 Firefox/10.0
Comment 1 Helping Hand 2012-02-17 07:47:41 UTC
Although this looks similar to bug 35570 it is not, earlier versions didn't have the bug 46230, there I could move the rows and columns the way they should.
Comment 2 Rainer Bielefeld Retired 2012-03-08 05:13:30 UTC
I believe "Bug 47096 - EDITING: Alt + Drag and Drop for complete rows impossible in particular documents" has thame roots.

@Helping Hand:
I believe I saw your problem during my tests for a.m. bug, but currently I can't reproduce you problem. Can you please attach a sample document and a document related step by step instruction?
Can yo confirm Bug 47096?
What was the last version where that worked for you?
Comment 3 Rainer Bielefeld Retired 2012-03-12 11:32:11 UTC
[Reproducible] with "LibreOffice 3.5.1.2 German UI/Locale [Build-ID: dc9775d-05ecbee-0851ad3-1586698-727bf66] on German WIN7 Home Premium (64bit) and sample document for "Bug 47096 - EDITING: Alt + Drag and Drop for complete rows impossible in particular documents" <https://bugs.freedesktop.org/attachment.cgi?id=58183>

Steps how to reproduce:
1. Download / Open a.m. sample document
2. Click on row header 67, move moue pointer with pushed left mouxe button to 
   row header 69, so that rows 37-69 will be selected
3. Click into A67, move mouse pointer upwards with pushed left mouse button to 
   drag and drop 3 lines
   Expected: complete rows moved
   Actual: only Cells A64:A69 will be moved.

And I succeeded to create a much more simple sample document, I will attach with next step.

Together with Bug 47096 that's really annoying.

@Kohei:
Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug
Comment 4 Rainer Bielefeld Retired 2012-03-12 11:33:12 UTC
Created attachment 58337 [details]
Simple Sample

To reproduce Bug please proceed as per Comment 2
Comment 5 Rainer Bielefeld Retired 2012-03-12 11:42:11 UTC
Works fine with parallel installation of MinGW Master "LibO-dev 3.5.0 Beta 1 – WIN7 Home Premium (64bit) English UI (Build ID: 8935521-b204871-3e50423-4c1bcb5) (daily/Win-x86@7-MinGW/master/2011-12-13_03.17.52)",

[Reproducible] with Parallel Dev-Installation of  "LibreOffice 3.5.0 Beta3- WIN7 Home Premium (64bit) German UI [Build-ID: e40af8c-10029e3-615e522-88673a2-727f724] 

I am really really sure that this one and Bug 47096 have the same roots (or Bug 47096 is a DUP)
Comment 6 Markus Mohrhard 2012-03-12 13:42:23 UTC
I will look into this one. This is most likely a regression introduced by Muthu's and my work on pasting for external applications.
Comment 7 Not Assigned 2012-03-12 17:30:29 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=2a26fe4a39b6f3b2af269b801340c32c28806250

only shrink to used area in text export, fdo#46230, related n#677811
Comment 8 Markus Mohrhard 2012-03-12 17:33:56 UTC
I hope I finally fixed all problems introduced by the original fix for n#677811.

We now only shrink the area to the used area when we use paste as text and not for every case.
Comment 9 Markus Mohrhard 2012-03-16 11:50:18 UTC
*** Bug 45868 has been marked as a duplicate of this bug. ***
Comment 10 OfficeUser 2012-03-16 12:09:54 UTC
Which build
Comment 11 OfficeUser 2012-03-16 12:10:24 UTC
What release will be the first fixed?
Comment 12 Markus Mohrhard 2012-03-17 20:43:56 UTC
*** Bug 47096 has been marked as a duplicate of this bug. ***
Comment 13 Markus Mohrhard 2012-03-17 20:45:06 UTC
*** Bug 47017 has been marked as a duplicate of this bug. ***
Comment 14 Not Assigned 2012-03-18 10:43:19 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=0ee518863337fba9bce019e05e24f527617a4321

also shrink used area for HTML in some cases, fdo#46230, n#677811
Comment 15 Not Assigned 2012-03-19 00:00:33 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "libreoffice-3-5":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=39228c6d2419636be04ee4a320a7c0ca08276f37&g=libreoffice-3-5

also shrink used area for HTML in some cases, fdo#46230, n#677811


It will be available in LibreOffice 3.5.2.
Comment 16 Not Assigned 2012-03-19 11:54:30 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "libreoffice-3-5":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a58d877fd576bacd738972a78c8310d4eccb0daa&g=libreoffice-3-5

only shrink to used area in text export, fdo#46230, related n#677811


It will be available in LibreOffice 3.5.2.
Comment 17 Markus Mohrhard 2012-03-28 09:23:53 UTC
*** Bug 48006 has been marked as a duplicate of this bug. ***
Comment 18 Markus Mohrhard 2012-04-01 13:51:30 UTC
*** Bug 48128 has been marked as a duplicate of this bug. ***
Comment 19 rpr 2012-07-01 09:14:23 UTC
I use LibO Calc 3.5.4.2 on Ubuntu 12.04 64-bit and I'd say the issue is still present.
Comment 20 OfficeUser 2012-07-01 09:29:30 UTC
@rpr.nospam:

Can you provide a spreadsheet?
Comment 21 Rainer Bielefeld Retired 2012-07-01 09:51:19 UTC
NOT reproducible with "LibreOffice  3.5.5.2  English UI/ German Locale  [Build-ID: 24b32b4-b87ec2e-85c8e98-87a4e20-9a1b8c1] on German WIN7 Home Premium (64bit) 

@rpr.nospam@gmail.com
<https://wiki.documentfoundation.org/BugReport_Details#How_to_reopen_Bugs>!
Comment 22 rpr 2012-07-01 10:42:03 UTC
Sorry, it's my fault. I didn't realize that the mouse pointer must be
placed inside the range of selected cells, and not at the column/row
header, for drag and drop to work. This should be mentioned somewhere
in the Help (e.g. under Moving Cells by Drag-and-Drop).
Comment 23 Rainer Bielefeld Retired 2012-07-01 10:56:48 UTC
@rpr.nospam@gmail.com
Thank you for quick feedback!