Description: Sometimes selecting cells doesn't select the user's intended range, and selects seemingly randomly instead. Steps to Reproduce: 1. Reset the user profile 2. Open Calc with a new blank sheet 3. Type 1, 2, 3, 4 into A1, A2, A3, A4 respectively 4. Copy A1:4 to C1:4 5. _Click_ in A1 6. Ctrl-click in A2 to extend the selection 7. Ctrl-click in C1 to extend the selection with a second disjoint range of cells 8. Ctrl-shift click in C2 to extend the second disjoint range 9. Hit Del to remove the contents of the selected cells 10. Ctrl-End to get to the bottom of the used cells 11. Ctrl-Home to get to A1 12. _Use the down arrow_ to move to A3 13. _Ctrl-shift down arrow_ to extend the selection to A4 14. Observe that the selection is _not_ A3:4 as expected Notes: In Step 5, clicking is key because... in Step 12 if one clicks in A3 instead of moving with the arrow keys, the problem _does not_ occur. Clicking appears to reset the bug. Step 9 is critical, skipping it causes the bug not to occur. It's probably any change but I didn't test that; I only checked that skipping the delete causes the bug not to occur. In the original sheet where I noticed this, I did a bunch of testing. Steps 7 and 9 are critical to the bug. Not doing exactly them causes the bug not to occur. It appears the bug depends on having a second disjoint range of cells that has been created with a shift-extend. It looks like the wrong selection is extended from the shift-extended second disjoint range from the previous selection. I'm betting something is not getting completely cleared when the selection is cancelled via keyboard, but is when cancelled via clicking. Actual Results: I'm not sure if the wrongly-selected cells are deterministic or not. In this reproduction, the actual selection is C:C. I repeated this a few times during typing up this bug report, and it was always the same wrong selection of cells, but, in the original sheet where I noticed this, the wrong selection varied. However, I think it might have varied deterministically. See the Notes after the reproduction steps above. Expected Results: A3:4 is selected Reproducible: Always User Profile Reset: Yes Additional Info: Version: 24.8.4.2 (X86_64) / LibreOffice Community Build ID: 480(Build:2) CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: en-CA (en_CA.UTF-8); UI: en-US Ubuntu package version: 4:24.8.4~rc2-0ubuntu0.24.04.1~lo1 Calc: threaded
reproduce Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8c2605aea05c6c5b9883400e1c1b7944f4edbc47 CPU threads: 12; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: en-US Calc: CL threaded I also think using shift key in step 8 is important. This did not occur when using only the keyboard.
In my reproduction steps, Step 8 is doing a shift-extend, but, the resulting range is equivalent to if a click-extend had been done, since the resulting range is only 2 cells long. However, in my original testing the shift-extend range was several cells in length. Redoing the test but click-extending one cell at a time to get the equivalent range caused the bug to not occur. The shift-extend is critical.
Updated last night. I can reproduce on Version: 24.8.5.2 (X86_64) / LibreOffice Community Build ID: 480(Build:2) CPU threads: 16; OS: Linux 6.11; UI render: default; VCL: gtk3 Locale: en-US (C.UTF-8); UI: en-US Ubuntu package version: 4:24.8.5~rc2-0ubuntu0.24.04.1~lo1 Calc: threaded
Still reproducible on: Version: 25.2.5.2 (X86_64) / LibreOffice Community Build ID: 520(Build:2) CPU threads: 16; OS: Linux 6.11; UI render: default; VCL: gtk3 Locale: en-US (C.UTF-8); UI: en-US Ubuntu package version: 4:25.2.5~rc2-0ubuntu0.24.04.1~lo1 Calc: threaded