https://bugs.documentfoundation.org/show_bug.cgi?id=172550
Bug ID: 172550
Summary: Scroll Lock state desyncs randomly in Calc on Wayland
(GNOME), arrow keys scroll sheet instead of moving
cell cursor
Product: LibreOffice
Version: 26.2.3.2 release
Hardware: All
OS: Linux (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Calc
Assignee: [email protected]
Reporter: [email protected]
Description:
Scroll Lock appears to toggle on its own (without the user pressing the
Scroll Lock key) while working in Calc. When this happens, arrow keys
scroll the visible sheet area instead of moving the cell cursor, making
normal navigation impossible.
The physical Scroll Lock key has no effect on Calc's internal lock state
once this occurs — pressing it does not toggle Calc out of the locked
behavior, even though the keyboard's hardware LED can be confirmed to
change state correctly via evtest.
This issue does NOT occur in other applications (terminal, text editors)
or in OnlyOffice, only in LibreOffice Calc — suggesting Calc is not
correctly reading/tracking the system Scroll Lock state under Wayland.
Steps to reproduce:
1. Open LibreOffice Calc on a Wayland session (GNOME)
2. Use the application normally; at some point Scroll Lock activates
spontaneously
3. Arrow keys now scroll the sheet view instead of moving between cells
4. Pressing the physical Scroll Lock key does not restore normal behavior
Expected behavior:
Arrow key cell navigation should not be affected by spurious Scroll Lock
state changes, and/or Calc should correctly sync with the actual system
key state so the physical key can toggle it back.
System info:
- OS: Ubuntu 26.04 LTS
- Desktop: GNOME 50
- Session type: Wayland
- Kernel: Linux 7.0.0-22-generic
- Keyboard: Dell KB216 Wired Keyboard (USB)
Additional diagnostic info (evtest output):
Using evtest on the keyboard device, we observed unsolicited EV_LED
events changing LED_SCROLLL and LED_NUML state without any corresponding
key press from the user — for example, triggered by pressing Enter:
Event: type 17 (EV_LED), code 2 (LED_SCROLLL), value 0
Event: type 17 (EV_LED), code 0 (LED_NUML), value 0
Event: type 4 (EV_MSC), code 4 (MSC_SCAN), value 70028
Event: type 1 (EV_KEY), code 28 (KEY_ENTER), value 0
This suggests the LED/lock state synchronization issue may originate at
the GNOME/Wayland compositor level rather than purely within LibreOffice,
but Calc's navigation behavior is the practical symptom affected.
Steps to Reproduce:
1. Open LibreOffice Calc on a system running GNOME 50 on Wayland
(Ubuntu 26.04), with a wired USB keyboard connected.
2. Use Calc normally for general data entry/navigation (typing in cells,
pressing Enter, moving between cells with arrow keys). There is no
single specific action that reliably triggers the issue — it occurs
intermittently during normal use, seemingly at random.
3. At some point, Scroll Lock becomes spontaneously active (confirmed via
`evtest` on the keyboard device — LED_SCROLLL state changes without
any Scroll Lock key press from the user). From this point on, pressing
the arrow keys in Calc scrolls the visible sheet view instead of
moving the cell cursor/selection.
4. Pressing the physical Scroll Lock key on the keyboard at this point
has no effect — Calc's navigation remains stuck in "scroll" mode. The
issue persists until the document/application is closed and reopened,
or in some cases requires a full session restart.
Note: The trigger appears to be non-deterministic. We were unable to
isolate a specific reproducible action, but the issue occurs reliably
within a normal working session (typically within 10-30 minutes of usage).
It has not been observed in other applications (terminal, gedit) or in
OnlyOffice on the same system, which suggests the issue is specific to
how LibreOffice Calc tracks/reacts to Scroll Lock state under Wayland.
Actual Results:
Scroll Lock becomes active on its own (without any user interaction with
the Scroll Lock key) during normal use of LibreOffice Calc. Once this
happens, pressing the arrow keys scrolls the visible area of the sheet
instead of moving the cell selection/cursor between cells. The physical
Scroll Lock key has no effect afterwards — pressing it does not restore
normal arrow key navigation in Calc.
Expected Results:
Arrow keys should always move the cell cursor/selection between cells,
unless the user has deliberately pressed the Scroll Lock key. If Scroll
Lock is active, the physical Scroll Lock key should reliably toggle it
off again so normal navigation is restored. Calc's internal lock state
should stay correctly synced with the actual system/keyboard state,
rather than getting stuck independently of it.
Reproducible: Always
User Profile Reset: No
Additional Info:
- evtest on the keyboard device confirms unsolicited EV_LED events
changing LED_SCROLLL/LED_NUML state, not triggered by any Scroll Lock
key press (observed even on pressing Enter), suggesting the issue may
originate from LED/lock-state handling at the GNOME/Wayland compositor
level, with Calc's navigation behavior being the practical symptom.
- The issue does not occur in OnlyOffice or other applications (terminal,
gedit) on the same system, only in LibreOffice Calc — pointing to a
Calc-specific handling of Scroll Lock state under Wayland.
- Tried switching to an "Ubuntu on Xorg" session as a workaround, but
this is no longer available in Ubuntu 26.04 / GNOME 50, as GNOME has
dropped Xorg session support entirely.
- Tried xdotool and ydotool to programmatically toggle Scroll Lock as a
workaround; neither resolved the issue (xdotool also requires a remote
desktop portal permission on Wayland which complicates the workaround).
System info:
- OS: Ubuntu 26.04 LTS
- Desktop: GNOME 50
- Session type: Wayland
- Kernel: Linux 7.0.0-22-generic
- Keyboard: Dell KB216 Wired Keyboard (USB)
--
You are receiving this mail because:
You are the assignee for the bug.
