Bug 165936 - Cursor is not moved correctly when using rows with merged cells in LibreOffice Writer
Summary: Cursor is not moved correctly when using rows with merged cells in LibreOffic...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.0 release
Hardware: All All
: lowest trivial
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
Depends on:
Blocks: Cursor
  Show dependency treegraph
 
Reported: 2025-03-27 16:24 UTC by hakan.stegborn
Modified: 2025-04-01 15:41 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description hakan.stegborn 2025-03-27 16:24:23 UTC
Description:
In a table with rows with several cells and row with all cells merged the cursor is not moved correctly. The cursor is not moved to the first cel on the row following the row with merged cells.

Steps to Reproduce:
1.Create a table with e.g. 3 columns and 3 rows.
2. Merge all cells on the second row
3. Position the cursor on the first cell in the first row.
4. Click on the down-arrow once - the cursor is moved to the row with merged cells
5. Click on the down-arrow once more - the cursor is moved to the middle cell on the third row

Actual Results:
The cursor is moved to the middle cell on the third row.

Expected Results:
The cursor is moved to the first cell on the third row.


Reproducible: Always


User Profile Reset: No

Additional Info:
None.
Comment 1 Juan Q. 2025-03-28 07:41:57 UTC
Hello hakan.stegborn@logifox.com 

Thank you for reporting the bug. I can confirm that the bug is present in 

Version: 25.2.1.2 (X86_64) / LibreOffice Community
Build ID: d3abf4aee5fd705e4a92bba33a32f40bc4e56f49
CPU threads: 12; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded

Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 1d8ff7bd62249ad0f825eaca18ea524d9d7c6c2e
CPU threads: 12; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded

The cursor movement is not consistent when using merged cells. 

Changing Status to NEW
Comment 2 Buovjaga 2025-03-28 16:50:26 UTC
Already in 3.5. But I'm not sure what the expected behaviour would be. Movement with arrow keys is not stored in undo history, for example, so obviously the program can't know which cell you started your journey from. Having it appear in the middle seems to be a middle ground solution and seems intentional (try with more columns than 3).

Let's show this to UX team.
Comment 3 hakan.stegborn 2025-03-31 07:17:21 UTC
I have just tried the steps below in Microsoft Excel. 

In this tool the result is according to expectations. 

It also works to move down from e.g. the third cell on the first row, to the merged row and then to the third cell on the third row, just by clicking on the down-arrow.
Comment 4 Heiko Tietze 2025-03-31 08:00:07 UTC
What do you expect if the content is centered? And isn't our solution more flexible assuming you sometimes want to change the last cell and not always the first.
Comment 5 Regina Henschel 2025-04-01 13:04:04 UTC
Word seems to track the cursor position in regard in which cell the cursor was and where in the cell it was. If such position exists in the row above/below, then it uses it when moving the cursor with up/down arrow key. If such position does not exists it still tries to use it in the next row you reach with the up/down arrow key. I think, that is more understandable and more user friendly than the current behavior of LibreOffice.

LibreOffice goes to the middle of the merged range. That makes it more cumbersome to work on the rows of a specific column when merged cells exist in between.