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
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.
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."
*** Bug 57008 has been marked as a duplicate of this bug. ***
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 ***
*** This bug has been marked as a duplicate of bug 146994 ***