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

[GoCoder7]

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!

[GoCoder7]

Update: Upstream Parley CJK/Korean Word Navigation Fix & Downstream Rollout Plan

During follow-up testing of macOS text navigation shortcuts (specifically Option + ArrowLeft/Right and Option + Backspace), we investigated an issue where word navigation jumped only one character at a time across Korean / CJK text rather than jumping across full words.

Root Cause (Upstream Parley)

This behavior was traced to Parley's text analysis and cluster layout:

• Parley merged UAX Integration with Accesskit #14 line break opportunities (Boundary::Line) and UAX add font size support #29 word boundaries (Boundary::Word) into a single Boundary enum, giving line breaks precedence.
• Under UAX Integration with Accesskit #14, CJK and Hangul syllables allow soft line breaks between almost every character, marking them as Boundary::Line.
• Cluster::is_word_boundary() then checked boundary != Boundary::None, treating every line break opportunity as a word boundary.

Upstream PR Submitted

We decoupled the UAX #29 word boundary flag into a dedicated bit in CharInfo / ClusterInfo and submitted the fix upstream to linebender/parley:

• Upstream PR: fix: decouple UAX #29 word boundaries from line break opportunities linebender/parley#819 (linebender/parley:main)

Backport for Parley 0.11.x Series

Because Blitz currently depends on parley = "0.11.1", we have also prepared and verified a backport patch against the 0.11.1 code line:

• Prepared Backport Branch: techton7/parley:blitz-v0.11.1-patch (3 files, +30, -7)
• We have offered this backport to the Parley maintainers for a potential 0.11.2 patch release.

Action Item for Blitz

No additional logic changes are required in blitz-dom—the fix is entirely inside Parley. Once Parley publishes v0.11.2 (or the next release) on crates.io, Blitz can simply bump the dependency in Cargo.toml:

# packages/blitz-dom/Cargo.toml
parley = "0.11.2"

(For local testing prior to release, [patch.crates-io] pointing to https://github.com/techton7/parley.git branch blitz-v0.11.1-patch confirms expected word-by-word jumping and deletion in wgpu_texture.)

[GoCoder7]

Upstream Update: Parley PR #819 Merged

The upstream PR resolving the CJK/Korean word boundary navigation issue has been merged into linebender/parley:main:

• Merged PR: fix: decouple UAX #29 word boundaries from line break opportunities linebender/parley#819 (Commit 86a878a)

The maintainer (@tomcur) approved and merged the fix, noting that it properly decouples UAX #29 word boundaries from UAX #14 line break opportunities. Two additional follow-ups are planned upstream to further improve boundary detection for scripts where dictionaries are unavailable.

Once these upstream updates are published in a new Parley release (either a 0.11.x patch or the next release), Blitz can bump the parley dependency in Cargo.toml to bring the complete fix to downstream users.