[Problem/Bug]: WebView2 input ignores programmatic IME conversion-mode toggle (Korean Hangul⇄alphanumeric); only hardware scancode works

What happened?

Related to #2071 (programmatic keyboard control in WebView2), but this is specifically about toggling the IME conversion mode (Korean Hangul ⇄ alphanumeric) within a single IME, not switching the input language/layout.

Environment

• OS: Windows 11 (build 26xxx)
• WebView2: Evergreen (Edge runtime), hosted in a Tauri v2 (2.11.x) app with a React/Vite frontend
• Korean Microsoft IME installed
• Key remapper: PowerToys Keyboard Manager, remapping CapsLock → Hangul (VK_HANGUL / 한/영)

Symptom

I remap CapsLock to the Hangul (한/영) toggle key via PowerToys Keyboard Manager. The remap correctly toggles the IME in every native app (Notepad, browsers, etc.), but inside a WebView2 text input (<input>/<textarea>) pressing CapsLock does not switch the IME to Hangul mode — the field stays in alphanumeric/English mode.

What I narrowed down

• The physical Hangul key (hardware key) does toggle the IME correctly inside the WebView2 input → WebView2 accepts a "real" Hangul key.
• Only the synthetic Hangul key injected by PowerToys is ignored (works everywhere else).
• From the native host side, calling ImmSetConversionStatus (IMM32) to force Hangul mode on the focused window does not work.
• Injecting the key via SendInput with scancode 0x72 (KEYEVENTF_SCANCODE | KEYEVENTF_EXTENDEDKEY for keydown, KEYEVENTF_KEYUP for keyup) does work.

So the only reliable method is a hardware-scancode-level injection. This suggests WebView2/Chromium (TSF-based) ignores both IMM32 API calls and injected virtual-key IME events, and only honors scancode-level input as an IME toggle.

Questions

1. Is it known/expected that WebView2 inputs ignore IMM32 calls and synthetic IME keys from remappers like PowerToys?
2. Is there a supported, TSF-compatible way to programmatically set/toggle the IME conversion mode (e.g. to Hangul) for the focused WebView2 input, for CJK-input apps?
3. Is this a WebView2/Chromium-level limitation, or is there a recommended host-side mitigation other than synthesizing a hardware scancode via SendInput?

Importance

Important. My app's user experience is significantly compromised.

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

No response

SDK Version

No response

Framework

Other

Operating System

Windows 11

OS Version

26200.8655

Repro steps

Steps to reproduce

1. Windows 11 with the Korean Microsoft IME.
2. In PowerToys Keyboard Manager, remap CapsLock → Hangul.
3. Focus a text field inside a WebView2-hosted webview.
4. Press CapsLock → the IME does not switch to Hangul (it works in every other app).

Repros in Edge Browser

No, issue does not reproduce in the corresponding Edge version

Regression

No, this never worked

Last working version (if regression)

No response

Start with the WebView2 text-input reproduction using the Korean Microsoft IME, PowerToys CapsLock-to-Hangul remap, and the corresponding Edge comparison. Investigate the native-host paths mentioned—ImmSetConversionStatus and SendInput scancode 0x72—and compare them with the WebView2/Chromium input behavior. Done means identifying whether a supported TSF-compatible approach exists or clearly documenting the confirmed limitation and mitigation.