DioxusLabs / DioxusLabs/blitz

macOS text input: cursor jumps 2 characters, Cmd navigation and clipboard actions not working

Open
#894 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
4.1k
Forks
203
Avg merge
8h 58m
Merged PRs (30d)
112

Description

Hi Blitz team! 👋

First of all, thank you so much for building such an amazing project and native renderer for Dioxus!

While testing text inputs on macOS, I noticed a few unexpected behaviors regarding keyboard navigation, shortcuts, and clipboard operations.

---

### Describe the bug

1. **Duplicate cursor movement on plain arrow keys**:
Pressing `ArrowLeft` or `ArrowRight` moves the cursor by **2 characters** instead of 1. Similarly, `Shift + Arrow` selects 2 characters at once.

2. **`Cmd + Arrow` line/document navigation does not work**:
Pressing standard macOS navigation shortcuts such as `Cmd + Left/Right` (jump to line start/end) or `Cmd + Up/Down` (jump to text start/end) does not move the cursor at all.

3. **`Cmd + Backspace` does not delete to line start**:
On macOS, `Cmd + Backspace` is expected to delete all characters from the cursor to the beginning of the line, but it does nothing.

4. **Clipboard actions (`Cmd + C`, `Cmd + V`, `Cmd + X`) are not handled in `AppleStandardKeyBinding`**:
`apply_apple_standard_keybinding` does not handle `copy:`, `cut:`, and `paste:` selectors.

5. **Typo in `moveToEndOfDocumentAndModifySelection:`**:
In `apply_apple_standard_keybinding`, the `"moveToEndOfDocumentAndModifySelection:"` branch calls `driver.move_to_text_end()` instead of `driver.select_to_text_end()`.

6. **Action shortcuts (`Cmd + A / C / V / X`) fail on non-Latin keyboard layouts**:
In `apply_keypress_event` and `handle_key_or_input_event`, shortcuts were matched solely against `Key::Character("a" | "c" | "v" | "x")`. On non-Latin layouts (e.g., Korean 2-Set where physical `KeyC` generates `ㅊ`), `logical_key` is non-ASCII, causing all shortcuts to fail completely. Shortcuts should prioritize physical key codes (`Code::Key*`) as standard OS conventions dictate.

---

### Root Cause & Architecture (Referencing VS Code and Zed's Pattern)

I looked into how VS Code and Zed design and handle platform-specific keyboard shortcuts on macOS:
- **Why `Cmd + Arrow` is ignored**: macOS AppKit's `interpretKeyEvents:` treats `Option` + arrows as text selectors (`moveWordLeft:`), but ignores the `Command` modifier for standard text input (treating it as application menu commands). As a result, `winit` never receives standard selectors for `Cmd` keystrokes and only emits raw `KeyPress` events with `SUPER`.
- **The double movement**: Plain arrow keys are emitted both as `AppleStandardKeyBinding("moveLeft:")` and `KeyPress(ArrowLeft)`.
- **Physical Key Mapping for Shortcuts**: Both macOS system conventions and editors like Zed map action shortcuts based on physical key positions (or command layout mapping) rather than layout-specific character glyphs.
- **Following this pattern in `blitz-dom`**: Plain/Option arrows are left to `AppleStandardKeyBinding` to avoid double movement, while `Cmd + Arrow`, `Cmd + Backspace`, and physical-key-mapped `Cmd + A / C / V / X` are cleanly handled in `apply_keypress_event`.

---

### Expected Behavior

- Plain `ArrowLeft` / `ArrowRight` moves cursor by exactly 1 character.
- `Option + ArrowLeft/Right` jumps by word (delegated to AppKit's `moveWordLeft:`).
- `Cmd + ArrowLeft/Right` moves cursor to line start/end (and with `Shift`, expands selection).
- `Cmd + ArrowUp/Down` moves cursor to document start/end (and with `Shift`, expands selection).
- `Cmd + Backspace` deletes from cursor to line start.
- `Cmd + A / C / V / X` operate reliably across all keyboard layouts (including Korean, Cyrillic, etc.).

---

### Environment

- **OS**: macOS
- **Crate**: `blitz-dom` (`packages/blitz-dom/src/node/text.rs`, `events/keyboard.rs`, `util.rs`)

---

### Additional Note

I already have a tested and verified fix ready for this issue (following the VS Code and Zed patterns) and submitted PR #895!

Also, as I'm actively building with and testing Blitz, I'd love to continue contributing by submitting issues and PRs whenever I find bugs or potential improvements. Would that be welcome?

Thanks again for the great work!

Contributor guide

Open the contributing guide

Research direction

The relevant code is in packages/blitz-dom/src/node/text.rs, events/keyboard.rs, and util.rs; begin by reviewing the keyboard event and AppleStandardKeyBinding paths. Compare the reported behaviors with PR #895 and its tests, which already contain a verified fix, rather than starting duplicate work.

Written by the indexing model from the issue text.

Assessment

Tech stack
macos, rust
Domain
desktop, frontend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Clearly specified
Newbie friendliness
15/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.