Skip to content

IME composition keys cannot edit committed document text #3300

Description

@jsmestad

Type: Bug
Severity: High. Editing an uncommitted IME composition can delete committed document text.
Related: #559, #816, #1177

What

Type committed text such as abc, begin an uncommitted Japanese input-method composition, then press Backspace. The input method should edit the marked composition. The current key path sends Backspace to the BEAM, where Insert mode deletes committed text behind the composition. Arrow keys similarly move the editor cursor instead of first serving the input method.

This is source-confirmed against main at ac343a9c2bc6. A full macOS input-method reproduction has not been run and is required for closure.

Why

Users must be able to correct composition text without damaging the document they already typed. A marked-text overlay must not coexist with unrelated editor movement or deletion caused by the same composition keys.

Acceptance Criteria

  1. While marked text is active, Backspace/Delete edits the composition according to the active input method and does not delete committed document text.
  2. Arrow and candidate-navigation keys reach the input method first. Consumed composition keys do not also move the BEAM cursor or change the document selection.
  3. Confirming a composition commits the input method's resolved text exactly once through the existing commit callback; cancelling it leaves committed content unchanged.
  4. Focus changes, composition cancellation, and switching panes or buffers cannot commit or delete text in a replacement target.
  5. Ordinary special keys outside composition, dead-key entry, modifier shortcuts, and native text fields retain their existing behavior.
  6. Native input-routing tests and real Japanese/Chinese composition checks verify intermediate marked text, committed buffer content, cursor position, and final commit/cancellation.

Developer Notes

Evidence: EditorNSView.swift:1554 maps and forwards special keys before inputContext.handleEvent. During marked text it handles only Escape and Return specially; Backspace and arrows reach sendKeyPress at line 1571. insert.ex:58 interprets Backspace as committed-buffer deletion.

Fix and ownership: While composition is active, let NSTextInputContext process composition keys before ordinary editor dispatch. The input method owns marked-text editing and candidate confirmation; BEAM continues to own committed document edits. Use the existing NSTextInputClient commit/unmark/cancel integration rather than synthesizing committed text directly from a raw Enter key. A consumed event must not fall through to sendKeyPress.

Verification: Drive actual EditorNSView.keyDown with a controlled input-context seam and an encoder spy; assert that Backspace and arrows during marked text emit no committed-buffer action when consumed. Cover composition updates, Return/candidate confirmation, Escape, focus loss, pane changes, and normal keys after composition ends. Complete the focused tests with a production macOS capture of committed abc, composing text, Backspace, and cancellation. Mock composition state alone cannot prove candidate-window behavior.

Scope and stop conditions: Preserve existing marked-text rendering, grapheme handling, and commit-target checks. Do not turn this into a new frontend editing model or let Swift modify the document directly. If the fix needs a new committed selection authority, revise the design first.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: macos-guimacOS native GUI frontend (Swift/Metal)bugSomething isn't workingpriority: criticalMust fix before releaseseverity: highWrong-target changes, lost input, unusable recovery, or substantial interaction degradation

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions