Bug 62436 - EDITING: Ctrl + arrow down jumps wrong when using Ctrl + v or x
Summary: EDITING: Ctrl + arrow down jumps wrong when using Ctrl + v or x
Status: RESOLVED DUPLICATE of bug 42535
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.6.2.2 release
Hardware: Other Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
: 57008 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-03-17 12:36 UTC by lyngeled
Modified: 2014-05-15 03:12 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
A spreadsheet test example (8.89 KB, application/vnd.oasis.opendocument.spreadsheet)
2013-03-17 12:36 UTC, lyngeled
Details

Note You need to log in before you can comment on or make changes to this bug.
Description lyngeled 2013-03-17 12:36:34 UTC
Created attachment 76643 [details]
A spreadsheet test example

Problem description: 
Ctrl + arrow down jumps to a wrong place when cutting or copying (using Ctrl + v or x or by the right click menu).

Steps to reproduce:
1. Fill some cells in a column
2. on the next cell under those just filled paste something
3. Press Ctrl + arrow down, it then jumps the number of cells (above) down

1. Fill some cells in a column
2. on the last cell in those just filled use cut
3. Press Ctrl + arrow down, it then jumps the number of cells (above) minus 1 down


Current behavior:
When doing the described action before using Ctrl + arrow down it jumps to wrong cell

Expected behavior:
Ctrl + arrow down should always jumps to the next nonempty cell or to the end of the Spread sheet, even when using cut or copy just before.
              
Operating System: Ubuntu
Version: 3.6.2.2 release
Comment 1 Clemen Beek 2013-03-21 19:15:33 UTC
Tried this and I can confirm this unexpected behaviour in LO 3.6.2.2 and 4.0.0.3. Both on AMD64 - Ubuntu 12.10.
Comment 2 tmacalp 2014-02-26 00:18:23 UTC
Interesting.  I can confirm this still affects LO 4.2.1.1 under Windows 32bit. 

It looks even more general than what you've described.  It appears that whenever you paste, your next action's range is checked from cell A1 instead of the actual cursor position.

My test:
1. Start a new spreadsheet
2. Insert a number in A10
3. Select any cell (C15 in this case)
4. Copy (Ctrl-C)
5. Paste into same cell (Ctrl-V)
6. Ctrl-down

You'll notice that your cell will cursor down the exact same number of cells it takes to go from A1 to your number in A10, leaving the cursor in C24.

This also works going horizontal...

1. Start a new spreadsheet
2. Insert a number in D1
3. Select any cell (C15 in this case)
4. Copy (Ctrl-C)
5. Paste into same cell (Ctrl-V)
6. Ctrl-right

Your cursor will travel to the right the same number of cells from A1 to D1 to end up in F15.

Because it's based on a faulty cursor check based on cell A1, this behavior should only be reproducible for cells in column A or in row 1. Otherwise, it will jump to the end of the range as expected.  

This faulty/unexpected behavior doesn't really inconvenience you unless you are actually selecting cells (ctrl-shift-arrow) as described in bug 42535, which appears to be related.  I'll add that bug as a "See Also."
Comment 3 tmacalp 2014-02-26 00:32:15 UTC
*** Bug 57008 has been marked as a duplicate of this bug. ***
Comment 4 tmacalp 2014-05-15 03:12:02 UTC
I'm pretty confident that this report is describing the same behavior as bug 42535, so I'll go ahead and mark this one as a duplicate.  Even though I think this one has a better description, that one is older.

*** This bug has been marked as a duplicate of bug 42535 ***