Bug 58440 - EDITING: Moving cells/columns/rows with drag and drop and modifier keys do not work as advertised (see comment #48)
Summary: EDITING: Moving cells/columns/rows with drag and drop and modifier keys do no...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.5.7.2 release
Hardware: All macOS (All)
: high normal
Assignee: Not Assigned
URL: https://help.libreoffice.org/7.6/en-U...
Whiteboard: BSA
Keywords:
: 61116 136389 (view as bug list)
Depends on:
Blocks: Cell-Management
  Show dependency treegraph
 
Reported: 2012-12-17 22:48 UTC by Martin Peter
Modified: 2024-01-31 12:51 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot for bug 58440, showing the page from LibreOffice Help in LibO 3.6.4.3 on Mac OS X (362.62 KB, image/png)
2012-12-24 08:18 UTC, Roman Eisele
Details
Screenshots comparing overwrite - ousting mode (116.43 KB, application/pdf)
2013-01-14 07:13 UTC, Rainer Bielefeld Retired
Details
Screenshot of LO Help on shortcuts for moving cells (235.69 KB, image/png)
2013-02-19 15:30 UTC, Martin Peter
Details
demonstration of rows reordering in Google Sheets (299.21 KB, image/gif)
2021-04-17 00:04 UTC, Jeff Fortin Tam
Details
Test case with current bug behavior in LO 24.2 (11.16 MB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2023-12-29 18:08 UTC, eisa01
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Peter 2012-12-17 22:48:26 UTC
Problem description: 

I used to move columns and rows several versions ago (~1year) without problems. I don't recall the exact keyboard shortcut while dragging a column to move it (it was ctrl+shift or cmd+shift or alt+ctrl or alt+cmd)

Steps to reproduce:
1. fill the first three fielda (A1,B1,C1) of row 1 with random data
2. select colum B by clicking the column header 
3a. grab the selection and drag it to the right of column C
3b. try the following shortcut-combinations while dragging the column (ctrl+shift or cmd+shift or alt+ctrl or alt+cmd)

Current behavior:

A: Column will get overwritten with a _copy_ of the dragged column 
OR
B: A _copy_ of the dragged column will be created, while the original column remains in place

Expected behavior:
column B _moves_ to C, and former C is now in column B

Thank you, bye

              
Operating System: Mac OS X
Comment 1 Rainer Bielefeld Retired 2012-12-18 05:46:48 UTC
I can't see any special Mac hint for this on <http://help.libreoffice.org/Calc/Moving_Cells_by_Drag-and-Drop>, so I believe reporter simply uses the wrong keys?

@Martin Peter
This is not a good place for "I don't remember" problems, please use <http://help.libreoffice.org/Calc/Moving_Cells_by_Drag-and-Drop>.

Please check whether Help hints work for you!
Comment 2 Martin Peter 2012-12-18 08:25:47 UTC
Hallo Rainer,

i justed tried this on my windows machine, and it works over there (LO 3.5.6.2).
On the windows box just pressing alt while D&D makes exactly what it should - it _moves_ the selected column from one place to another.

On my mac machine pressing alt while D&D copies the column instead of moving it.

As for the "i don't remember" problem, where are one step further.

This problem obviously wasn't unique to me and apparently it had been solved for win systems:
http://ask.libreoffice.org/en/question/1143/how-to-move-columnsrows-in-lo35/

Do you need more information?

Thanks for any help to come.

Martin
Comment 3 Rainer Bielefeld Retired 2012-12-18 12:24:01 UTC
Hm, I also have a (different?) problem with LibO 3.4 and 3.5.4 on Ubunu on VirtualBox, because alt+mouseclick is for windowsmanager (as mentioned on ask.libreoffice). I wonder whether this also is a current Linux Problem. 
Of course this problem is completely different to reporter's, the sum might be thet this <alt+drag&drop> is a "WIN only" solution and works nowhere else?

Roman, can you confirm this problem?
Comment 4 Roman Eisele 2012-12-19 14:06:36 UTC
(In reply to comment #3)
> Roman, can you confirm this problem?

Well, I have tried the steps given in comment #0 with LibreOffice 3.6.4.3 (Build ID: 2ef5aff) on Mac OS X 10.6.8, and I see a problem, but a different one: no matter what combination of keys I press (Cmd, Alt, Ctrl, Shift, and all their combinations), the column does neither move nor gets copied at all; the only thing that changes sometimes is the number of selected columns.

But maybe I am just too stupid, or was not patient enough ...
Comment 5 Rainer Bielefeld Retired 2012-12-19 17:00:36 UTC
(In reply to comment #4)
A little more detailed description

1. fill the first three fielda (A1,B1,C1) of row 1 with random data
   (for example "a","b","c")
2. select colum C by clicking the column header 
3. <Alt> (or whatever required for Mac)
4. Click into C2, keep mouse button pushed
5. Start moving mouse pointer to the left
   Mouse pointer changes to "Not here" in C2
6. When you have trespassed border C->B Mouse pointer changes to "Move",
   Border between coluns B-A becomes bold
7. When you have reach middle of Be release mouse button
   > Contents of columns B,C have interchanged.
That's the way how it works with WIN, and this does not work under Ubuntu (May be because of other reasons).

If a last attempt failed please please make this one new for Markus, he already fixed other bugs ("Bug 46230 - EDITING: impossible to perform a drag & drop of entire row/column").

Some Hints:
In German help you find instructions under "Zellen per Ziehen&Ablegen verschieben", please check after we have finished here whether Help has to be amended.
Mouse pointer View see "Ziehen&Ablegen innerhalb der LibreOffice-Dokumente"
Comment 6 Martin Peter 2012-12-20 11:27:16 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Roman, can you confirm this problem?
> 
> Well, I have tried the steps given in comment #0 with LibreOffice 3.6.4.3
> (Build ID: 2ef5aff) on Mac OS X 10.6.8, and I see a problem, but a different
> one: no matter what combination of keys I press (Cmd, Alt, Ctrl, Shift, and
> all their combinations), the column does neither move nor gets copied at
> all; the only thing that changes sometimes is the number of selected columns.
> 
> But maybe I am just too stupid, or was not patient enough ...

Hi. I guess you are trying do drag the column by clicking on the header. The dragging operation should be started with a click into the column-selection. The selection itself is achieved by clicking the column-header once, after selecting, you drag the selected fields.

The key to hold for (expected) moving of columns should by ALT as i found out by now. In Win it works just fine.

Regards
Comment 7 Roman Eisele 2012-12-23 19:31:48 UTC
@ Rainer Bielefeld: thank you very much for your detailed instructions!

Testing with LibreOffice 3.6.4.3 on Mac OS X 10.6.8 (Intel), I get the following results.


(I) Pressing no keys at all
---------------------------

When I follow Rainer’s instructions from comment #5, but do NOT press any key, i.e. leave out step 2, and just drag column C between column A and B, I would expect the following result:

   |   A   |   B   |   C   |   D   | ...
-------------------------------------------------
1  |a      |c      |b      |       | ...

But I get this result:

   |   A   |   B   |   C   |   D   | ...
-------------------------------------------------
1  |a      |c      |       |       | ...

I.e., the contents of column C overwrite the contents of column b, instead of ousting them.

But this is not a bug, because the LibreOffice help says (in section “moving cells by drag and drop”):

No key:     Cells are moved and overwrite the cells in the target area.
            Source cells are emptied.

Strange, but so it reads, and therefore this is what is expected.


(II) Pressing Alt key
---------------------
Following Rainer’s instructions from comment #5, including keeping the <Alt> key pressed during the whole drag-and-drop action, I get the following contents in Columns A to D after step 7:

   |   A   |   B   |   C   |   D   | ...
-------------------------------------------------
1  |a      |c      |b      |c      | ...

So column C has been *copied* (not moved) between columns A and B.

On Mac OS, pressing <Alt> is often used for copying data instead of moving them. So this could be intended behaviour.

The LibreOffice help says (in section “moving cells by drag and drop”):

Option key   Cells are moved and shift the cells in the target area
             to the right or to the bottom. Source cells are emptied,
             except if you move within the same rows on the same sheet.
             If you move within the same rows on the same sheet,
             the cells in the target area shift to the right,
             and then the whole row shifts to fill the source area.

I confess that IMHO this description is somewhat irritating. There should not be any “except if...” clauses in descriptions of expected behaviour.
But if I understand the description corectly, the current behaviour is correct: the “except if you move within the same rows on the same sheet” applies, and so the source cells are not emptied.


Do you want me to test more key combinations? Until now, I only see irritating descriptions, but not a bug. But maybe I am just too stupid for this kind of tests. (I prefer real bugs that crash LibreOffice ;-)
Comment 8 Roman Eisele 2012-12-23 20:24:46 UTC
(In reply to comment #7)
> But maybe I am just too stupid for this kind of tests.
> (I prefer real bugs that crash LibreOffice ;-)

Sorry for the loose wording. What I wanted to say is: IMHO the expected behaviour, as described by the LibreOffice help in the section “moving cells by drag and drop”, is so irritating and counter-counterintuitive, at least when we speak about dragging and dropping whole columns or rows, that I feel frustrated by judging what is a bug or not, because the expected behaviour feels like a bug to me ...

So, just tell me if you want me to test more key combinations, and I will describe my results, but if the results are a bug or not a bug should be judged by somebody else. (I would just regard the complete expected behaviour as a bug.)
Comment 9 Martin Peter 2012-12-23 20:38:46 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > But maybe I am just too stupid for this kind of tests.
> > (I prefer real bugs that crash LibreOffice ;-)
> 
> Sorry for the loose wording. What I wanted to say is: IMHO the expected
> behaviour, as described by the LibreOffice help in the section “moving cells
> by drag and drop”, is so irritating and counter-counterintuitive, at least
> when we speak about dragging and dropping whole columns or rows, that I feel
> frustrated by judging what is a bug or not, because the expected behaviour
> feels like a bug to me ...
> 
> So, just tell me if you want me to test more key combinations, and I will
> describe my results, but if the results are a bug or not a bug should be
> judged by somebody else. (I would just regard the complete expected
> behaviour as a bug.)

Thanks for your efforts.

Is it intended, that LibrOffice on Mac lacks the moving-columns-capability, which exists in the Windows version of Libre Office?

Regards
Martin
Comment 10 Roman Eisele 2012-12-23 20:53:32 UTC
(In reply to comment #9)
> Is it intended, that LibrOffice on Mac lacks the moving-columns-capability,
> which exists in the Windows version of Libre Office?

This is what the LibreOffice help says:

> No key
> Cells are moved and overwrite the cells in the target area.
> Source cells are emptied.
>
> Command key
> Cells are copied and overwrite the cells in the target area.
> Source cells stay as they are.
>
> Command+Shift keys
> Links to the source cells are inserted and overwrite the cells
> in the target area. Source cells stay as they are.
>
> Option key
> Cells are moved and shift the cells in the target area to the right
> or to the bottom. Source cells are emptied, except if you move within
> the same rows on the same sheet. If you move within the same rows
> on the same sheet, the cells in the target area shift to the right,
> and then the whole row shifts to fill the source area.
>
> Option+Command keys
> Cells are copied and shift the cells in the target area to the right
> or to the bottom. Source cells stay as they are.
>
> Option+Command+Shift keys
> Links to the source cells are inserted and shift the cells in the target
> area to the right or to the bottom. Source cells stay as they are.


Can you find the alluded “moving-columns-capability” in this list?
If not, it is really missing ...
Comment 11 Rainer Bielefeld Retired 2012-12-24 06:56:16 UTC
(In reply to comment #10)
Currently it looks as if Mac LibO is lacking this function.

Additional there might be a Help problem, but I d not know whether Mac has it's own Help texts different from WIN Help?

From where is the Help citation? In WIKIHELP 
<https://help.libreoffice.org/Calc/Moving_Cells_by_Drag-and-Drop>
I only find the non-Mac wording, and in Manual 3.4 "Using Spreadsheets in LibreOffice" I can't find anything concerning this drag and drop.
Comment 12 Roman Eisele 2012-12-24 08:18:24 UTC
Created attachment 72059 [details]
Screenshot for bug 58440, showing the page from LibreOffice Help in LibO 3.6.4.3 on Mac OS X



(In reply to comment #11)
> From where is the Help citation?

From the “LibreOffice Help”, available inside of the LibreOffice application via the “Help” menu; the page is entitled “Moving Cells by Drag-and-Drop”, and available when I select “LibreOffice Calc” from the pop-up menu at the top left of the Help menu, switch to the “Index” tab, and search the index for “moving; cells by drag and drop”. Please cf. the attached screenshot. It shows the US English version of the help.
Comment 13 Roman Eisele 2012-12-24 08:21:36 UTC
(In reply to comment #11)
> Additional there might be a Help problem, but I d not know whether Mac has
> it's own Help texts different from WIN Help?

I would guess it has, because (cf. my screenshot) the help text talks about the Command key, which is specific to Mac OS X. But please compare the text visible on my screenshot to the version available in LibreOffice for Windows. If there are any substantial differences, it is clear that there are platform-specific versions of the LibreOffice help.
Comment 14 Rainer Bielefeld Retired 2013-01-14 07:13:39 UTC
Created attachment 72990 [details]
Screenshots comparing overwrite - ousting mode

(In reply to comment #13)
Due to comment and screenshot Help seems ok, that's a plausible equivalent of the function I expect and see in WIN

The Mac test seems to be:
1. fill the first three fielda (A1,B1,C1) of row 1 with random data
   (for example "a","b","c")
2. select colum C by clicking the column header 
3. Click into C2, keep mouse button pushed
4. Start moving mouse pointer to the left
   Mouse pointer changes to "Not here" in C2
6. When you have trespassed border C->B Mouse pointer changes to "Move",
   Border around column B between become bold
7. When you reached middle of B2 press <Alt> (or whatever required for Mac)
   Black border at right of column B should disappear, what announces that 
   column D will shift right old column b contents.
8. Release mouse button
   > Contents of columns B,C have interchanged.

The question is  whether you can find any Key (combination) what will let disappear right border in step 6
Comment 15 Rainer Bielefeld Retired 2013-02-19 13:52:28 UTC
*** Bug 61116 has been marked as a duplicate of this bug. ***
Comment 16 Martin Peter 2013-02-19 15:30:57 UTC
Created attachment 75119 [details]
Screenshot of LO Help on shortcuts for moving cells
Comment 17 Martin Peter 2013-02-19 15:34:05 UTC
(In reply to comment #14)
> [...]
> 7. When you reached middle of B2 press <Alt> (or whatever required for Mac)
>    Black border at right of column B should disappear, what announces that 
>    column D will shift right old column b contents.
> 8. Release mouse button
>    Contents of columns B,C have interchanged.
> 
> The question is  whether you can find any Key (combination) what will let
> disappear right border in step 6

The key combination, that lets te right border disappear on mac are "alt" or "alt + ctrl". 

While the result of the drag&drop operation with both key/key-combinations is identical, the behaviou while performing the operation is slightly different.

1) D&D Column C and pressing "alt":
 * A green "+" icon appears next to the pointer, indicating a copy operation
 * The right border dissappears
 * Result: C ousted B to the right, but a copy has been created instead of moving now it looks like this:
  |  A  |  B  |  C  |  D  |
----------------------------
1 |  a  |  c  |  b  |  c  |


2) D&D Column C and pressing "alt + ctrl":
 * The right border dissappears (no icon appears)
 * Result: see above, exactly as 1) when pressing "alt"


So 1) and 2) have the same result, while the appearing "+"icon whilst performing the drag and drop operation is the only difference.

Although it isn't documented I suppose the combination "alt + ctrl" to be ment for "moving" columns because it lacks the "+" icon but it's still removing the right border as one would expect for the moving operation.

LIBRE OFFICE HELP

I attached a screenshot of the mac manual with the drag and drop shortcuts (attachment 75119 [details]). It is somewhat confusing and even erroneous. The "Command" key is beeing confused with the "Control" key. For example: using the Command key alone has no effect at all, whilst performing drag & drop operations on cells, rows or columns - the help claims the opposite. So, the help seems to be messed up seriously at this point.
Comment 18 breakphreak 2013-02-19 17:36:40 UTC
So, is there any key combination that allows the rows/columns to be moved by dragging?
Comment 19 breakphreak 2013-02-19 17:37:37 UTC
*** Bug 61116 has been marked as a duplicate of this bug. ***
Comment 20 Martin Peter 2013-02-19 19:05:02 UTC
(In reply to comment #18)
> So, is there any key combination that allows the rows/columns to be moved by
> dragging?

No, not to my knowledge. That's why i filed this issue. I consider this a OSX specific application bug in combination with an erroneous documentation.
Comment 21 breakphreak 2013-02-19 19:11:49 UTC
I've also checked with 4.0 version - same issue. And, also checked with the latest version of Open Office - same issue. This is a very common (missing) functionality to me, wonder how other people are coping with the issue.
Comment 22 Pietro Amaranto 2013-05-23 17:19:23 UTC
(In reply to comment #20)
> (In reply to comment #18)
> > So, is there any key combination that allows the rows/columns to be moved by
> > dragging?
> 
> No, not to my knowledge. That's why i filed this issue. I consider this a
> OSX specific application bug in combination with an erroneous documentation.

I totally agree: this is an OSX SPECIFIC BUG since ever.
I had the same issue with OpenOffice but only on OSX platform.
I never had problems on Windows versions.

On OSX I never had the chance to move&insert cells with drag&drop.
As Martin well explained on #17: two different GUI behavior -> same result.

I was waiting for the new release but this limitation persists.
Comment 23 Joel Madero 2013-05-24 15:54:25 UTC
Marking as NEW due to last comment
Comment 24 snellpacha 2013-07-17 16:44:22 UTC
Any idea when this recurring bug under OSX will be adressed ?
Latest version to this day under OSX (4.0.4.2) has the bug. Too bad !
Comment 25 Joel Madero 2013-08-13 14:56:07 UTC
If you're going to up the importance please tell us why - we tend to not like just priorities jumping up. Use this flowchart: https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg to help guide you in determining the appropriate priority.
Comment 26 snellpacha 2013-08-13 17:06:57 UTC
According to the flowchart, marking it as HIGH doesn't seem outrageous to me : this bug is a productivity killer and surprinsingly it's been around for quite a long time. In the end, it could lead users to head for some other piece of software. I doubt it should be too difficult to fix, but I might be wrong on this one, as I'm not a developer.

Feel free to lower it back, and thank you to the community for the hard work. It's a great piece of software despite of all.

Best regards.
Comment 27 a430095 2014-03-27 10:45:01 UTC
This should be HIGH priority!

This problem is still not resolved in 4.1.4.2 release. Instead of "moving cells" by alt-drag&drop (as described in help file) the software does a copy&insert. Nothing gets overwritten, but data gets duplicated. If you want to rearrange a bunch of rows (lets say each row represents a country and you want to sort these rows by drag&drop) you and up with a lot of duplicated rows and often end up deleting the wrong ones. It really cost me a lot of time compared to LO Windows an all Excel versions!

PLEASE FIX!

Alex
Comment 28 Joel Madero 2014-06-11 22:41:20 UTC
Please don't update version - version is oldest version the problem is confirmed on.
Comment 29 QA Administrators 2015-07-18 17:44:46 UTC Comment hidden (obsolete)
Comment 30 Pietro Amaranto 2015-08-20 11:57:36 UTC
The bug is still present with the same behavior in every OSX version since it was noticed.
Comment 31 Joel Madero 2015-08-20 15:42:53 UTC
In the future please pay closer attention to prompts - version is "earliest version" and when you change it to a later version a big warning comes up saying that it's supposed to be earliest version. Reverting last change.
Comment 32 Martin Peter 2015-12-06 10:47:54 UTC
Confirming that the problem still exists years after reporting 
Tested with LibreOffice 4.4 on recent Mac OSX OS (Yosemite, El Capitan).
Comment 33 QA Administrators 2017-05-22 13:40:56 UTC Comment hidden (obsolete)
Comment 34 cpohle 2017-05-23 13:28:15 UTC
Confirm the bug still exists in 5.3.3 on macOS. Dragging with CTRL+ALT copies instead of moves a column, although no "+" icon is shown next to the mouse cursor.
Comment 35 Iain 2017-08-13 16:08:54 UTC
I can confirm that this still exists in LibreOffice Version: 5.4.0.3 on MacOs 10.12.6

Dragging a column as described, while holding the alt key results in the column being copied rather than moved.
Comment 36 superurbi 2017-10-04 10:08:01 UTC
The same to me but in my case it doen't work at all, I'm using LO 5.4.2.2 x64 on Windows 10 PRO x64
Comment 37 molnium 2018-03-22 09:42:49 UTC
I can confirm this behavior on LibreOffice Version: 6.0.2.1 on Mac.

Since making a copy by pressing the option-key (also named 'alt'-key) is commonly used in Mac OSX system-wide, it makes sense that a column also gets copied that way.

But if I press option+command while pasting in Finder for instance: then it moves the previously selected file there.

On the other hand: in Numbers app moving columns works simply by pressing and holding the primary mouse button on the column title and then drag and drop it to the desired destination.
I would suggest that way as the most intuitive way to do it in LibreOffice on Mac.
Comment 38 LC 2018-04-27 04:26:40 UTC
Using a Mac - alt/option copies, but doesn't move the rows/columns.

Any idea when this will be fixed or is this not perceived as a problem?
Comment 39 QA Administrators 2019-06-06 02:53:22 UTC Comment hidden (obsolete)
Comment 40 cpohle 2019-06-13 08:06:48 UTC
Bug ist still present:

Version: 6.2.4.2
Build-ID: 2412653d852ce75f65fbfa83fb7e7b669a126d64
CPU-Threads: 4; BS: Mac OS X 10.14.5; UI-Render: GL; VCL: osx; 
Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE
Calc: threaded
Comment 41 Jivan Pal 2020-08-16 23:12:10 UTC
Behaviour is still present.

Version: 7.0.0.3
Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e
CPU threads: 4; OS: Mac OS X 10.15.6; UI render: default; VCL: osx
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

This is such a basic bit of functionality, and to get it so wrong... I really don't understand how this has been overlooked for almost 8 years. The "ALT to copy" functionality which is currently exhibited is contrary to the LibreOffice documentation (as mentioned earlier in this thread), but *does* match the conventions of macOS. Having said that, there is still currently no way in LibreOffice Calc for macOS to simply rearrange rows and columns like one is able to in MS Excel or Google Sheets.

"NEW" is not a reasonable status for this issue to have. Is this issue WONTFIX? If not, what is the expected timeframe in which this will be addressed?
Comment 42 Jeff Fortin Tam 2021-04-17 00:04:29 UTC
Created attachment 171246 [details]
demonstration of rows reordering in Google Sheets

This isn't MacOS-specific. On Linux (GTK3 version), dragging rows/columns is impossible, no matter if you select them first, use alt/ctrl/shift/ctrl+alt/ctrl+shift/alt+shit while dragging with the mouse, etc. There just is no way to reorder rows/columns at all, as far as I can tell. Do I need to file a new bug about that platform specifically, or should we just adjust the title and platforms of this bug to reflect that?

Alt+dragging cells works, but not rows/columns, and I don't care about cells because I could use cut & paste for those. Cut & paste doesn't work for rows/columns however, because you need to be able to insert "between" other rows/columns.

Meanwhile, Google Sheets lets you reorder simply by selecting the rows/columns and then dragging them around, no keyboard modifiers required, which makes a ton more sense in my view (because if I wanted to drag-select multiple rows/columns, I wouldn't be clicking/selecting first). You can see that behavior in action in the gif file I am attaching now.
Comment 43 beatgammit 2021-04-29 21:22:11 UTC
I did some messing around with it and found a workaround. Holding down Option will copy the currently selected column and allow it to be inserted next to a target column. The original column could then be deleted.

I haven't tested this on Linux (will try to do that later) or Windows, so I'm not sure if there's a similar workaround.

Excel supports moving cells by:

1. select a column/row
2. hold shift while clicking at the edge of the column next to a cell, not the header
3. release the click in the desired location before releasing shift

This works on my Mac (Catalina).
Comment 44 QA Administrators 2023-09-16 03:22:00 UTC Comment hidden (obsolete)
Comment 45 cpohle 2023-09-18 10:16:06 UTC
Comment #43 is still valid as of LO 7.6.1.2

(In reply to QA Administrators from comment #44)
> If the bug is present, please leave a comment that includes the information
> from Help - About LibreOffice.
Comment 46 QA Administrators 2023-09-19 03:06:03 UTC Comment hidden (obsolete)
Comment 47 eisa01 2023-12-29 17:57:11 UTC
*** Bug 136389 has been marked as a duplicate of this bug. ***
Comment 48 eisa01 2023-12-29 18:07:37 UTC
Updated title and added two duplicates: There's a few problems that are interlinked

I have uploaded a test case with a table copy-pasted from the Help section describing the keyboard shortcuts and how they should work

Some operations work as advertised, while others do not
Using control instead of command fixes some of the issues, but not all, so there is something wrong somewhere :)
Comment 49 eisa01 2023-12-29 18:08:39 UTC
Created attachment 191638 [details]
Test case with current bug behavior in LO 24.2
Comment 50 steve 2023-12-31 12:04:09 UTC
Upping priority to High and added URL link to documentation.
Comment 51 steve 2023-12-31 12:16:22 UTC
This is such an old bug, that a ton of things has changed in aspects touching on this bug. Documentation has changed, macOS keyboard shortcut handling has changed.

I revisited https://help.libreoffice.org/7.6/en-US/text/scalc/guide/move_dragdrop.html?&DbPAR=SHARED&System=MAC and tried to reproduce the documented behavior:

✅ No key: Cells are moved and overwrite the cells in the target area. Source cells are emptied

❌ Command key: Cells are copied and overwrite the cells in the target area. Source cells stay as they are.
In my test, whenever I select a cell, press cmd and try to drag the selected cell over another cell, the cells between are highlighted. While I would call this expected behavior, documentation about this is then false.

❌ Command+Shift keys: Links to the source cells are inserted and overwrite the cells in the target area. Source cells stay as they are.
Same as command only key.

❌ Option key: Cells are moved and shift the cells in the target area to the right or to the bottom. Source cells are emptied, except if you move within the same rows on the same sheet.
In my test this did nothing. No content was copied or moved when dragging A7 to A3 with all cell fields filled with test text.

❌ Option+Command keys: Cells are copied and shift the cells in the target area to the right or to the bottom. Source cells stay as they are.
In my test this did nothing.

Option+Command+Shift keys: Links to the source cells are inserted and shift the cells in the target area to the right or to the bottom. Source cells stay as they are.
In my test this did nothing.
Comment 52 steve 2023-12-31 12:59:26 UTC
Test environment:
Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 0f6f5048d223731aa52b768a77244d0208711391
CPU threads: 8; OS: macOS 13.6.3; UI render: Skia/Raster; VCL: osx
Locale: de-DE (en_DE.UTF-8); UI: en-US
Calc: threaded
Comment 53 Jeff Fortin Tam 2024-01-24 14:13:47 UTC
> This is such an old bug, that a ton of things has changed in aspects touching on this bug. Documentation has changed, macOS keyboard shortcut handling has changed.

Contrary to what I previously said in comment #42, on Linux with 7.6.x (and presumably the upcoming 24.2) on Linux I can confirm that selecting the whole row/column and then alt-dragging the cells (not the column/row header) works. I don't know if I somehow had not observed correctly back then, or if the behavior indeed changed since 2021. I don't know if this works for Mac (or Windows) users now.

This trick (when it works) remains very counterintuitive though, and this bug report has become a bit confusing in scope. I'd like again to propose the "Google Sheets" UX behavior for all platforms as per comment #42; would it make sense to make a new simple ticket out of that (to start fresh with a simpler scope), or it'll just be considered a duplicate of this one here?
Comment 54 ady 2024-01-31 12:51:23 UTC
(In reply to steve from comment #51)
> I revisited
> https://help.libreoffice.org/7.6/en-US/text/scalc/guide/move_dragdrop.
> html?&DbPAR=SHARED&System=MAC and tried to reproduce the documented behavior:
> 

> ❌ Command key: Cells are copied and overwrite the cells in the target area.
> Source cells stay as they are.


> In my test, whenever I select a cell, press cmd and try to drag 

In case it is not clear, the procedure is (AFAICT):

1. Select the range area you want to copy/move/link_to. If it is only one cell, press the mouse button on the desired cell, move it slightly out of the cell and return it back to the desired cell, without releasing the mouse button.
2. Release the mouse. The intended area is now marked (painted/colored) as selected.
3. Press the mouse button on some point _within_ the selected area; do not release the mouse button.
4. Drag the mouse in such a way that the selected area covers the intended destination area.
5. Without releasing yet the mouse button, now add the additional keyboard combination key(s) if needed (according to the desired action to be performed), and keep the whole combination still pressed.
6. When the expected result is shown on your expected destination area (with different "border" and pointer styles according to the expected action), release the mouse button (only). > The expected result should be performed now.
7. Only now release the additional keyboard combination keys, if any such combination was used in step 5.

I am not saying it is the most user-friendly procedure, but it is the procedure that is described in the official help documentation for LO 7.6 (or at least that is the way I understand it, and that's how I proceed in LO Calc).