Operating system

macOS

Orca version

1.4.110

Details

Summary

When using a Japanese IME (or any CJK IME) to rename a worktree, tab, workspace, or window title, pressing Enter to confirm an IME conversion candidate prematurely commits the rename instead of only completing the composition. This is the same class of bug as #742, but in a different set of inputs that the earlier fixes did not cover.

The Enter handlers in these rename inputs appear to fire whenever event.key === "Enter", without guarding against IME composition state such as event.isComposing.

MDN reference: https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/isComposing

Steps to reproduce

1. Open Orca and focus a workspace tab.
2. Press ⌘R to start renaming the tab (also reproduces from the right-click → Rename menu).
3. Enable a Japanese IME (e.g. macOS Japanese — Romaji).
4. Type text that requires conversion, e.g. にほんご.
5. Press Space to bring up conversion candidates.
6. Press Enter to confirm a candidate.

The same sequence reproduces in:

• Worktree card inline rename input
• Workspace rename input (⌘⇧R)
• Window title rename input

Expected behavior

Pressing Enter while IME composition is active should only confirm the conversion candidate. The rename input should stay open, and the rename should not be committed. A subsequent, non-composition Enter press should commit the rename.

Actual behavior

The first Enter — intended only to confirm the IME candidate — is treated as a rename submit. The rename is committed with whatever text the input contained at that moment, often leaving the entry with a half-converted or unintended name. The user then has to undo and rename again, or avoid the keyboard shortcut entirely.

Affected places

• Worktree card inline rename input
• Tab rename input (⌘R)
• Workspace rename input (⌘⇧R)
• Window title rename input

Suspected cause

This is the same pattern as #742: the Enter handler calls submit() on event.key === "Enter" without checking composition state, so it fires while the IME is still confirming a candidate.

Prior IME-related fixes only addressed other inputs:

• [Bug]: Workflow creation popup submits on Japanese IME Enter confirmation #742 / PR fix: suppress Enter submit during IME composition in workflow creation popup #804 — Workflow creation popup
• PR fix(settings): prevent IME composition cancellation in repository Display Name and Worktree Location inputs #4632 — Settings Display Name
• PR fix(settings): defer Display Name persistence until IME composition ends #6238 — Settings Display Name (follow-up)

The rename inputs themselves were introduced or touched in PR #3280 (tab/workspace rename shortcuts ⌘R / ⌘⇧R) and PR #3296 / PR #3298 (worktree rename input focus handling), but none of those added an isComposing guard.

Suggested fix

Add an isComposing guard to the Enter handler in the worktree, tab, workspace, and window rename inputs. For example:

if (event.key === "Enter" && !event.isComposing && event.keyCode !== 229) {
  commitRename()
}

The keyCode === 229 fallback is a defensive check for browsers/IMEs that do not consistently set isComposing on keydown.

Impact

Affects every CJK IME user (Japanese, Chinese, Korean) across every rename surface in the app. With Orca's recent mobile launch and the growing CJK community, this is a frequent and very visible papercut — users typically have to undo and rename again, or avoid the keyboard shortcuts altogether.