https://bugs.documentfoundation.org/show_bug.cgi?id=172584
Bug ID: 172584
Summary: LibreOffice Calc regression: cursor/navigation
commands scroll display instead of moving selected
cell; BASIC dispatcher movement macros fail
Product: LibreOffice
Version: unspecified
Hardware: All
OS: Windows (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Calc
Assignee: [email protected]
Reporter: [email protected]
Title:
LibreOffice Calc regression: cursor/navigation commands scroll display instead
of moving selected cell; BASIC dispatcher movement macros fail
Product:
LibreOffice
Component:
Calc
Operating System:
Windows 11 Pro
LibreOffice Version:
[Enter exact version from Help > About LibreOffice]
Problem Summary:
LibreOffice Calc navigation appears broken. Keyboard/dedicated up/down
navigation and BASIC dispatcher movement commands no longer move the active
selected cell reliably. Instead, the visible sheet display scrolls while the
selected cell remains in place. This breaks existing Calc macros that have
worked for months and depend on moving the selected cell before copying/pasting
data.
Impact:
This is a critical workflow regression for my Calc workbook. My daily
stock-update workbook depends on LibreOffice Basic macros that move the active
cell, copy values, paste values between sheets, and reposition the cursor for
the next update. These macros previously worked. Now the screen scrolls but the
selected cell does not move, so macros copy from or paste to the wrong
location.
Observed Behavior:
1. Starting selected cell was tested at Sheet1.HER17.
2. Running a minimal BASIC macro using `.uno:GoUp` with By=2 caused the visible
display to scroll from top row 15 to top row 13.
3. The selected cell did not move.
4. Similar problems occur with left/right/up/down movement logic used in
existing macros.
5. Dedicated keyboard arrow movement and the hidden up/down display arrows now
appear to move only the display instead of moving the active selected cell.
6. Macros using `.uno:GoUp`, `.uno:GoDown`, `.uno:GoLeft`, `.uno:GoRight`, and
related cursor-dependent dispatcher actions now fail or operate on the wrong
cell.
7. Calc reports errors such as “There is not enough space on the sheet to
insert here” when the macro is thrown into the wrong location after failed
cursor movement.
Expected Behavior:
`.uno:GoUp`, `.uno:GoDown`, `.uno:GoLeft`, `.uno:GoRight`, and normal
cell-navigation keys should move the selected active cell, not merely scroll
the display. Existing BASIC dispatcher macros should continue moving the
selection as before.
Minimal Reproduction Macro:
Sub Test_GoUp_Only
```
Dim document As Object
Dim dispatcher As Object
document = ThisComponent.CurrentController.Frame
dispatcher = createUnoService("com.sun.star.frame.DispatchHelper")
Dim args1(1) As New com.sun.star.beans.PropertyValue
args1(0).Name = "By"
args1(0).Value = 2
args1(1).Name = "Sel"
args1(1).Value = False
dispatcher.executeDispatch(document, ".uno:GoUp", "", 0, args1())
```
End Sub
Steps to Reproduce:
1. Open a Calc `.ods` workbook.
2. Select a cell in the sheet, for example Sheet1.HER17.
3. Run the minimal macro above.
4. Observe whether the selected cell moves up two rows.
5. In my case, the visible display scrolls, but the selected cell remains
unchanged.
Additional Macro Context:
A previously working production macro used this logic:
* Start on Sheet1 at a variable current update location.
* Move up two rows to copy a date.
* Paste that date into Sheet3.I1.
* Move left/right/up/down to copy previous values.
* Use copied values to update Sheet3 and Sheet1.
This has become unreliable because the active cell no longer moves as expected.
Workaround Attempted:
I rewrote parts of the macro to avoid dispatcher movement by directly reading
and writing cell ranges through the API, for example using fixed ranges like
Sheet3.F2:F11 to Sheet3.G2:G11. That workaround confirms the workbook data
itself is not the problem. The failure is specifically tied to Calc
cursor/selection movement and dispatcher navigation behavior.
Why This Matters:
The same workbook and macro process worked before. The behavior changed
recently and now prevents daily updates from running. This appears to be a
regression in Calc cursor/selection handling or BASIC dispatcher navigation.
Requested Fix:
Please investigate why Calc movement commands and/or keyboard navigation are
scrolling the display instead of moving the selected active cell, and restore
the previous behavior where `.uno:GoUp`, `.uno:GoDown`, `.uno:GoLeft`, and
`.uno:GoRight` move the selected cell reliably.
--
You are receiving this mail because:
You are the assignee for the bug.
