Confirm a composed character with Enter on the desktop question box, instead of sending the question

[kevin9327]

What happens

On the desktop app's last setup screen, "Ask it something", type the question in Japanese, Chinese or Korean. Those languages are typed through an input method (IME): letters build a character, and Enter confirms it.

That Enter also sends the question. It goes to the Bot with its last character still unconfirmed, and the screen shows an answer to a question nobody finished typing. The chat composer inside OpenBot does not do this. This box does.

Why

desktop/src/Ask.tsx:

onKeyDown={(event) => {
  if (event.key === "Enter" && !asking) {
    ask();
  }
}}

The Enter that confirms a composed character is still a keydown with key === "Enter". Browsers mark it in one of two ways, depending on engine:

• Chromium sets isComposing: true on it;
• WebKit fires it after compositionend, so isComposing is already false, but its keyCode is 229. WebKit is the desktop app's webview on macOS.

MDN's keydown documentation gives exactly this guard for ignoring keydowns that belong to a composition: event.isComposing || event.keyCode === 229.

The chat composer's own Enter already skips it. prompt-area, which draws it, checks !event.nativeEvent.isComposing on every Enter branch, so this box was the one that did not.

The change

The same condition, plus the 229 half for WebKit:

if (
  event.key === "Enter" &&
  !asking &&
  !event.nativeEvent.isComposing &&
  event.keyCode !== 229
) {
  ask();
}

An ordinary Enter still asks, and the Ask button is untouched.

Where it runs

• New state that outlives a request? None.
• Second replica? Not applicable; this is the desktop setup window.
• Serialised / fanned out / new listener? None.

Boundary and audit

Untouched. This screen calls ask_the_bot; nothing on the gateway path changes.

Changelog

A line under Unreleased, since the setup screen behaves differently for anyone typing through an input method.

Proof

Two tests in desktop/src/App.test.tsx, which already drives setup through to this screen. They share a small reachAsk() helper built on the existing useCompatibleEndpointSetup and enterCompatibleEndpoint.

1. the Enter that finishes a composed character does not ask the Bot fires both shapes above at the focused question box and expects no ask_the_bot.
2. an ordinary Enter in the question box asks the Bot, once is the pin.

bun test src/App.test.tsx -t "composed character|ordinary Enter", with Ask.tsx as it is on main (absolute paths shortened to the repository root, nothing else edited):

bun test v1.3.14 (0d9b296a)

src\App.test.tsx:
168 |   // macOS webview — sends it after `compositionend` with the key code 229 instead.
169 |   await act(async () => {
170 |     fireEvent.keyDown(question, { key: "Enter", isComposing: true });
171 |     fireEvent.keyDown(question, { key: "Enter", keyCode: 229 });
172 |   });
173 |   expect(asked()).toEqual([]);
                        ^
error: expect(received).toEqual(expected)

- []
+ [
+   {
+     "args": {
+       "question": "What is 17 times 23?",
+       "root": "/tmp/openbot-app-test",
+     },
+     "command": "ask_the_bot",
+   },
+   {
+     "args": {
+       "question": "What is 17 times 23?",
+       "root": "/tmp/openbot-app-test",
+     },
+     "command": "ask_the_bot",
+   },
+ ]

- Expected  - 1
+ Received  + 16

      at <anonymous> (desktop\src\App.test.tsx:173:19)
(fail) the Enter that finishes a composed character does not ask the Bot [1089.11ms]

 1 pass
 61 filtered out
 1 fail
 2 expect() calls
Ran 2 tests across 1 file. [2.48s]

Both confirming Enters sent the question. With the change: 2 pass, 0 fail.

Not a widening. The pin, an ordinary Enter in the question box asks the Bot, once, is the 1 pass above: it passes before and after. The only presses this changes are the two that belong to a composition.

Whole desktop suite (bun test in desktop/):

	main	this PR
desktop	95 pass, 0 fail	97 pass, 0 fail

The delta is the two tests added. bun run typecheck in desktop/ exits 0. bunx @biomejs/biome check and bunx prettier --check are clean on Ask.tsx and App.test.tsx. prettier --check CHANGELOG.md reports style issues, but it does on main too: every suggestion is a missing blank line further down the file, none in the lines added here.

What was and was not measured: the handler's response to the two event shapes, above. I could not drive a live input method in a webview on this machine, so the claim about which shape each engine sends rests on MDN's documented guard rather than on a recording.

One harness detail: the test clicks into the field before pressing keys. Under happy-dom, React handles a keydown on an input through its input-event polyfill, which tracks the focused element, so a keydown on an input nobody focused throws inside React rather than reaching the handler. Clicking in first is also how a person reaches the box.

Note: the same shape in the web app

Three inputs in app/ act on a bare event.key === "Enter" as well:

• the single-line field in components/agents/agent-dialog.tsx (editing a coworker's name and similar);
• Enter-to-continue in components/agents/create-agent-dialog.tsx;
• the rule box in routes/_authed/admin/boundaries.tsx.

I left them out rather than fold a second package into this change. None of those components has a test that renders it yet, and each would need its own query and fetch setup. Happy to send them separately if you would like the same guard there.

Note on the CHANGELOG

The entry goes at the top of ## Unreleased, the one line every entry goes at, so it will conflict with #506 and any other PR open against that anchor. Happy to rebase whenever it suits you.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[davidmckayv]

Thanks, and the IME-composition bug is a real one. Closing it, though, because it is in the desktop app (desktop/), which is not something we are taking external contributions on right now: it is unreleased and unsigned, and we want to shape that surface ourselves before it ships. Please hold off on desktop-app PRs for the moment. Non-desktop fixes are very welcome and we merge those readily.