After shifting one or more cells from one position to another, the attempt to enhance the selected area with Shift-ArrowKey (up, down, left, right) results in a selection of A2 to current selection's upper left cell. How to reproduce 1. click/select cell B3 (doesn't matter if cell is empty) 2. press Shift-Del (or Ctrl-X) 3. press ArrowKeyRight (focus is on D3 now) 4. press Shift-Ins (or Ctrl-V) 5. press Shift-ArrowKeyDown Instead of the expected enhancement of the selected area from D3:D3 to D3:D4 the selected area is A2:D3. Even if you paste to another table or a new spreadsheet/file, as soon as you press Shift-ArrowKey (up, down, left or right) the selected area changes to A2:xy where 'xy' is the upper left cell of the recently inserted area. The only workaround to prevent this misbehavior is to unselect the copied area after step 4 and reselect it before step 5. This is not new in version 7.1.8. I saw it since I switched from Excel to Calc several years ago.
Hi, Thank you for a bug report. I'm not sure if this is a bug or property. I mark this as a new "bug" and let see what specialists thinks. Same thing happens with: Version: 7.2.5.2 (x64) / LibreOffice Community Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5 CPU threads: 12; OS: Windows 10.0 Build 22000; UI render: Skia/Raster; VCL: win Locale: fi-FI (fi_FI); UI: en-US Calc: CL And with: Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 52443996eff721e612ac4afc1eb1a53bb8a3e06f CPU threads: 12; OS: Windows 10.0 Build 22000; UI render: Skia/Raster; VCL: win Locale: fi-FI (fi_FI); UI: fi-FI Calc: CL
Also repro using LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 but not in OOo 3.3.0, nor in OOo 3.2.0, nor in AOO 4.1.0. Eike: do you have an idea if this is intentional? (looks a clear bug to me.)
If that's intentional I'd like to see the reasoning..
This was from AskLibreoffice question https://ask.libreoffice.org/t/calc-cell-selection-using-shift-and-arrow-key-unintentionally-jumps-to-upper-left-corner-a1/73199/7 I wondered if it were intentional because of the different selections with different arrow keys. The question really is whether it is useful in any way, probably not. Either way, if I paste in the new cell then use Shift+Arrow keys I get: Shift+Left = select to A1 Shift+Right = select to B1 (excludes first column) Shift+Down = select to A2 (excludes first row) Shift+Up = select to A1 Ctrl+Shift+Down = Select to beginning of row Ctrl+Shift+Right = select to B1 (excludes first column) Ctrl+Shift+Left = no change Ctrl+Shift+Right = no change Clicking Shift+Backspace makes normal selection possible. Cheers, Al
I suspect regression from https://git.libreoffice.org/core/+/ac3b66057ba677903b6de354317417b267be0fa0 > author Kohei Yoshida <kyoshida@novell.com> Thu Sep 16 11:09:29 2010 +0200 > committer Fridrich Štrba <fridrich.strba@bluewin.ch> Thu Sep 16 11:09:29 2010 +0200 > calc-selection-fixed-cursor.diff: Migrated > > n#502717, i#21869, i#97093, when making selection, don't move the cursor position It is absent in OOo/AOO; it introduced the ScTabView::ExpandBlock that implements current block expansion logic in "normal selection mode" case. The problem there is that previous cell paste has initialized Own block mode; and thus nBlockEndX and nBlockEndY are both 0 (i.e., A1). InitBlockMode isn't executed (even if you remove the if, the function has own internal check), so the variables don't get adjusted. And the movement (moveCursorByProtRule, moveCursorByMergedCell) operate based on that (0,0). But I do not understand the implications, so I beware to touch the code.
(In reply to Mike Kaganski from comment #5) > But I do not understand the implications, so I beware to touch the code. I don't think anyone does, to be honest. ;-) I originally wanted to set up a suite of test cases for this code, but I never had a chance. It's not trivial since the code is in the view part of Calc. The logic here gets pretty complex, and I'm not surprised there is issues. But ideally this code needs to be properly unit-tested if someone can figure out the way...
I think I have an idea to initialize the own block mode better.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7055ad90927d0d2e0dc5eab3774322e386fe2b15 Resolves: tdf#146994 InitOwnBlockMode() with current mark range or cursor pos It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9266bc555f52e64b32f505c32ed5008fd3a14e7d tdf#146994: sc_uicalc: Add unittest It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** This bug has been marked as a duplicate of bug 68703 ***
*** Bug 68703 has been marked as a duplicate of this bug. ***
*** Bug 87388 has been marked as a duplicate of this bug. ***
*** Bug 42535 has been marked as a duplicate of this bug. ***
*** Bug 62436 has been marked as a duplicate of this bug. ***
*** Bug 57008 has been marked as a duplicate of this bug. ***
*** Bug 132936 has been marked as a duplicate of this bug. ***
*** Bug 109298 has been marked as a duplicate of this bug. ***