[Bug] Forcing input source switch during active composition in Chrome omnibox leaves orphaned candidate window

[liby]

Summary

With Browser Rules → Address bar default input source = ABC enabled for Chrome, starting to type the first character in the Chrome address bar while a Pinyin input source is active leaves the composition in an unusable state.

Environment

• Input Source Pro 2.9.0 (605)
• macOS 26.4 (Tahoe), Apple Silicon
• Google Chrome 147.0.7727.102 (Official Build, arm64)
• Input source: macOS built-in Pinyin – Simplified

Preferences (relevant subset)

browserAddressDefaultKeyboardId = "com.apple.keylayout.ABC"
isEnableURLSwitchForChrome      = 1
isEnableURLSwitchForChromium    = 1
isEnableURLSwitchForSafari      = 1

Steps to reproduce

1. In Input Source Pro → Browser Rules, set Address bar default input source to ABC and ensure Chrome is checked.
2. Launch Google Chrome (regular window).
3. Manually switch the current input source to Pinyin – Simplified.
4. Focus the address bar (omnibox) while it is empty, then press any letter key (e.g. n).

Expected

Either the address bar rule does not override the user's manual selection, or if it does switch to ABC, the previous Pinyin composition is cancelled cleanly so the address bar receives subsequent keystrokes normally.

Actual

• The input source is switched to ABC after the first keystroke.
• The behavior after the switch depends on what the Pinyin IME's first candidate was at that moment:
  • If the first candidate is a Latin letter (e.g. the letter itself, which Pinyin offers as an option), it is committed to the address bar and the candidate window closes. Typing appears to "just work" as ABC.
  • If the first candidate is a CJK character, nothing is committed to the address bar. The candidate window stays on screen.
• When the candidate window is stuck:
  • Pressing Enter does not select any candidate and does not navigate.
  • Pressing Delete / Backspace has no effect on the address bar text.
  • The only way to recover is to manually toggle the input source once; the candidate window dismisses and the address bar becomes responsive again.

If the address bar is not empty when typing begins (for example, there is already a Latin letter in it), subsequent Pinyin input works normally — the rule does not appear to trigger mid-field.

Recording walkthrough

Screen.Recording.2026-04-22.at.14.02.01.mov

A short screen recording is attached. The capture is cropped to the address bar to avoid exposing personal search suggestions, so the viewport is small. Timeline:

1. Empty address bar, Pinyin active → type a key whose first Pinyin candidate is a Latin letter. Input source flips to ABC, the letter is committed to the address bar, candidate window closes.
2. Address bar not empty → continue typing Pinyin. Composition proceeds normally, candidates are selectable, Enter navigates as expected.
3. Empty address bar, Pinyin active → type a key whose first candidate is a CJK character. Input source flips to ABC, nothing is committed, the candidate window stays on screen.
   • In the stuck state, Enter does nothing, Delete / Backspace does nothing.
   • Manually toggle the input source. Candidate window dismisses, address bar becomes responsive.

Additional observations

• Reproduces in a regular Chrome window and in an Incognito window with the same profile.
• Does not reproduce when Chrome is launched with a separate --user-data-dir from the command line; the address bar rule does not appear to trigger at all against that instance. (Same Chrome binary, same bundle identifier.)
• Unchecking Chrome in Browser Rules (equivalent to isEnableURLSwitchForChrome = 0) avoids the issue entirely.

Related

• Vivaldi (Chromium-based browsers) freeze on macOS 26 Tahoe due to IMKInputSession deadlock triggered by input source switching #92 — similar IME-switching interaction with Chromium-based browsers, but the user-visible symptom there is a multi-second freeze rather than a stuck composition.
• [Bug] 在切换到中文（或任何有候选框的输入法）时经常显示已切换但仍然还是英文 #85 — opposite direction (switching into CJK silently fails); listing for context, not claiming duplication.