Skip to content

fix(desktop): leave Enter and Escape to an IME composition in log and page search - #153803

Open
wonjangcloud9 wants to merge 1 commit into
NousResearch:mainfrom
wonjangcloud9:fix/desktop-log-search-ime
Open

wonjangcloud9 wants to merge 1 commit into
NousResearch:mainfrom
wonjangcloud9:fix/desktop-log-search-ime

Conversation

@wonjangcloud9

Copy link
Copy Markdown

What does this PR do?

The desktop app's chat log search and page find bar now leave Enter and Escape alone while an input method (Korean, Japanese, Chinese) is still composing.

  • Log search skipped the shared IME check for Enter. LogSearchField (components/chat/log-search.tsx) mapped Enter to next/previous itself and only asked findBarKeyAction for other keys. findBarKeyAction already ignores a composing Enter (Desktop text fields no longer submit on IME composition Enter (salvage #94611, port cloudflare-os#291) #95245 made that the shared policy), but this field never reached that check. On macOS a Korean Enter arrives twice, as keyCode 229 while the last syllable is composing and then 13, so a single Enter stepped two matches. A Japanese Enter that only confirms a conversion stepped one.
  • A composing Escape closed the search. findBarKeyAction mapped every bare Escape to close. In Japanese and Chinese, Escape cancels the conversion. So the page find bar closed mid-query, and the log search cleared the whole query (its close is onChange('')).

Now findBarKeyAction returns null for any key inside a composition, and LogSearchField uses it for Enter too. Enter and Shift+Enter keep their meaning. A modified Enter (⌘/Ctrl/Alt+Enter) no longer steps matches in log search, the same as in the page find bar.

Related Issue

No issue. #95245 added the shared isImeComposing policy and its Enter case in findBarKeyAction, and this applies it to the call site that bypassed it and to Escape. I searched for duplicates with "log-search", "LogSearchField", "findBarKeyAction", "find bar IME" and "search composition desktop".

Type of Change

  • 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

  • apps/desktop/src/lib/find-in-page.ts: findBarKeyAction returns null when isImeComposing(event), covering Escape as well as Enter. The Enter branch drops its own check, which is now redundant.
  • apps/desktop/src/components/chat/log-search.tsx: const action = findBarKeyAction(event, { inInput: true }).
  • apps/desktop/src/components/chat/log-search.test.tsx (new): Enter, Shift+Enter and Escape still step and clear. A composing Enter (isComposing, keyCode 229), the post-composition Enter with keyCode 229, and a composing Escape do nothing.
  • apps/desktop/src/components/find-bar.test.tsx: findBarKeyAction returns null for a composing Escape.

How to Test

  1. pnpm exec vitest run --project ui src/components/chat/log-search.test.tsx src/components/find-bar.test.tsx in apps/desktop. On main the two new cases fail: search.next is called twice by the composing Enters, and expected 'close' to be null. Both pass here.
  2. pnpm exec vitest run --project ui src/components/chat/log-search.test.tsx src/components/find-bar.test.tsx src/lib: 234 files, 2304 tests passed.
  3. tsc -p . --noEmit, ESLint on the changed files (0 problems; find-bar.test.tsx has the same 9 warnings as on main), and scripts/check are clean.

I tested with synthetic keyboard events (testing-library) and did not drive the packaged Electron app with a real IME.

Checklist

Code

  • I've read the Contributing Guide
  • My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
  • I searched for existing PRs to make sure this isn't a duplicate
  • My PR contains only changes related to this fix/feature (no unrelated commits)
  • I've run just test on the tests for the code I changed, and they pass
  • just check passes (the blocking lint and code-health checks CI runs)
  • I've added tests for my changes (required for bug fixes, strongly encouraged for features)
  • I've tested on my platform: macOS 27 (arm64)

Documentation & Housekeeping

  • I've updated relevant documentation (README, docs/, docstrings) — N/A
  • I've updated cli-config.yaml.example if I added/changed config keys — N/A
  • I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — N/A
  • I've considered cross-platform impact (Windows, macOS): renderer-only keyboard logic, same on every platform
  • I've updated tool descriptions/schemas if I changed tool behavior — N/A

🤖 Generated with Claude Code

… page search

The chat log search field mapped Enter to next/previous itself before it
asked findBarKeyAction, so it skipped the IME check that function already
has for Enter. On macOS a Korean Enter arrives twice (keyCode 229 while the
last syllable composes, then 13), so one Enter stepped two matches; a
Japanese Enter that only confirms a conversion stepped one.

findBarKeyAction also mapped a composing Escape to "close". A Japanese or
Chinese Escape cancels the conversion, so the page find bar closed and the
log search cleared the query being typed.

findBarKeyAction now returns null for any key inside a composition, and
the log search uses it for Enter too (Enter and Shift+Enter keep their
meaning; a modified Enter no longer steps, as in the page find bar).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@alt-glitch alt-glitch added comp/desktop Electron desktop app (apps/desktop/*) P2 Medium — degraded but workaround exists type/bug Something isn't working labels Nov 11, 2026

This branch has not been deployed

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

Labels

comp/desktop Electron desktop app (apps/desktop/*) P2 Medium — degraded but workaround exists type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants