Cursor becomes stuck when moving upward with `k` in Vim mode

[uNyanda]

• Date: 2026-07-18
• Type: Bug
• Severity: Medium

Environment

• OS: Linux
• WM: Niri
• Compositor: Wayland
• Software version: 2.14.0

Description

While navigating a note in Vim mode using k, the cursor can become stuck and stop moving upward even though there are still lines above it. Downward movement with j continues to work normally.

Steps to reproduce

1. Open a long note.
2. Enable Vim mode.
3. Scroll down through the note.
4. Press k repeatedly to move back up.

Expected Behaviour

Pressing k should continue moving the cursor upward one line at a time until the beginning of the note is reached.

Actual Behaviour

The cursor becomes stuck and can no longer move upward, even though there are still lines above the current cursor position. Repeatedly pressing k has no effect, while j continues to move the cursor downward normally.

Additional Notes

Note

• The issue only affects upward movement with k.
• Downward movement with j continues to work as expected.
• Disabling Word wrap prevents the issue from occurring. The issue is only reproducible when Word wrap is enabled.
• Three screen recordings are attached demonstrating the issue consistently.

Screenshots

Case 1

Case 2

Case 3

[adibhanna]

Fixed in 4a81f0d, shipping in v2.15.0.

Diagnosis: the j/k motion in ZenNotes moves by display line so it steps through soft-wrapped rows, and it does so with a pixel-based search (CodeMirror's moveVertically, via coordsAtPos/posAtCoords). When those coordinate lookups are sub-pixel-imprecise — most commonly under a compositor's fractional display scaling, which Niri/Wayland setups often use — the search can land back on the same visual row, so the motion fails to advance and the cursor sticks at a wrap boundary. With word wrap off, each display line is a logical line, so the pixel path isn't exercised — which is why disabling wrap avoided it.

Fix: j/k now fall back to a plain logical-line step whenever the display-line move doesn't actually make progress in the requested direction (and a line is available that way), so the cursor always keeps moving. On setups where the pixel motion is accurate this changes nothing — it only kicks in to rescue a stuck motion.

A note on verification: I couldn't reproduce the freeze itself on my hardware (integer display scaling — headless Chromium and macOS both stepped through wrapped rows fine across many notes), which is consistent with this being a fractional-scaling coordinate-precision issue. I verified the fix two ways: unit tests for the fallback logic, and an end-to-end run where I forced the pixel motion to never advance (simulating the stuck condition) and confirmed k still climbs to the top via the fallback instead of freezing.

If you're able to, a quick confirmation on your Niri/Wayland setup once v2.15.0 is out would be appreciated — long note, word wrap on, k up through it. Thanks for the detailed report and the recordings, @uNyanda.