Description: Assume a table of multiple rows. Two of the rows have more text than a third row. If I place the cursor in part of one of the longer rows and then use the arrow keys to move between the rows, the cursor remembers where it was on the longer rows even when moving through the short row. But if I edit one of the longer rows in any way, and then move the cursor through the short row, it gets stuck at the end of the short row and remains there when moving to the longer row. This is true even if I move the cursor inside the row after making the edit. Please see the attached video and steps to reproduce. This bug is a significant drag on my work flow, which frequently involves lining up parallel lines of texts of different lengths in tables using fixed width fonts. Steps to Reproduce: 1. Create a table with 3 rows and 1 column. 2. Type "A b c" into the first and third rows, and "A b" into the second row. 3. Put the cursor before "c" in the top row. Hit the down arrow. Notice that the cursor is after the b in the second row. Hit the down arrow again. Notice that the cursor goes back to being before the c in the bottom row. 4. Delete the space before the "c" in the bottom row, and then reinsert it. The cursor should now be before the c. 5. Hit the up arrow. Notice that the cursor is now after the b in the second row. 6. Hit the up arrow again. Notice that the cursor is now after the b in the first row, instead of before the c, where it should be. 7. Hit the right arrow to move the cursor before the c in the first row. 8. Hit the down arrow. Notice that the cursor is after the b in the second row. Hit the down arrow again. Notice that the cursor is now (correctly) before the c in the last row. Actual Results: Cursor gets "stuck" after the final position in the second row when moving to the top row after editing the bottom row. Expected Results: Cursor should have returned to the same position it had been in the bottom row when moving to the top row after editing the bottom row. Reproducible: Always User Profile Reset: No Additional Info: Version: 24.8.2.1 (X86_64) / LibreOffice Community Build ID: 480(Build:1) CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Ubuntu package version: 4:24.8.2-0ubuntu0.24.04.1~lo1 Calc: threaded
Created attachment 197567 [details] Video demonstrating the bug
Hi William, I could reproduce this in Version: 24.8.2.1 (X86_64) / LibreOffice Community Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13 CPU threads: 2; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded I am not sure if this considered a bug, but it indeed is inconsistency.
Repro the different behaviour of cursor placement after removing and reinserting whitespace already with 3.5. Arch Linux 64-bit Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b710ba48503372ddaf10a17ce7f4f3340bc8adb8 CPU threads: 8; OS: Linux 6.14; UI render: default; VCL: kf6 (cairo+wayland) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded Built on 7 May 2025