Fix the issue where AI predictions cannot be directly committed and instead trigger word-creation mode, and fix the issue where words generated by AI predictions cannot be deleted via right-click.
The toolbar occasionally stayed invisible while its host window looked
perfectly healthy: the HWND was shown at the right position and size, so
screenshot tools could still frame it, but WebView2 never painted into
it. Two independent causes, both specific to the toolbar.
The toolbar was the only small window left out of the cloaked warmup, so
whenever no client was active at startup its controller was created
against a hidden host and WebView2 never finished raster setup. The later
ShowWindow could not repair that.
The toolbar was also the only small window not renotified after
HWND_TOPMOST was applied. Pinning moves the host between z-bands, and in
a uiAccess process a WebView2 that is not told about it keeps compositing
against the old parent state. The toolbar reports navigation-ready last,
so the topmost gate normally opened inside its own navigation-completed
handler, before it had painted a single frame.
Changes:
- Warm up the toolbar host DWM-cloaked like the candidate and menu hosts,
and express hide as a cloak until the first navigation completes so the
warmup cannot be cut short. HideFloatingToolbarHost replaces the raw
ShowWindow(SW_HIDE), including in the fullscreen hook.
- Give the toolbar the same post-topmost put_Bounds +
NotifyParentWindowPositionChanged the menu host already had.
- Defer the first topmost application to a later message-loop turn via
WM_APPLY_SMALL_WINDOW_TOPMOST, and route EnsureSmallWindowsTopmost
through the same path so it can no longer pin inline.
- Add an opt-out diagnostic trace (ftb-diagnostic.log, disabled with
MSIME_FTB_DIAG=0) recording every visibility decision together with the
host and controller state, plus the foreground window behind a
fullscreen hide.
Also drops the earlier attempt at deriving g_is_ime_active from the IPC
active client, which targeted a different failure mode than the one
actually reproduced.
WM_IMEACTIVATE could be dropped or skipped when activation was unchanged,
leaving the floating toolbar hidden until the user switched IME away and
back. Derive g_is_ime_active from the live active client on every visibility
apply, and re-apply once the FTB WebView finishes its first navigation.
Also restore Watchdog startup with a short profile-ready retry window.
Drop TrayMenuDiag / DescribeHostWindow and all call sites added while
debugging the uiAccess TOPMOST WebView2 init failure, now that the fix
is verified.
In a uiAccess=true process, a WS_EX_TOPMOST parent window causes
WebView2's internal cross-process SetParent to be rejected by UIPI,
returning E_INVALIDARG (0x80070057) from CreateCoreWebView2Controller.
This was triggered when the watchdog restarted the server while the IME
was already active: the floating toolbar showed early, which mistakenly
raised the DWM-cloaked (warmup) menu host to TOPMOST before its
controller existed. Manual launches never hit this because the IME was
inactive at startup time.
Changes:
- Gate RaiseTrayMenuAboveSmallWindows on menu controller existence so
a cloaked warmup host is never prematurely pinned TOPMOST.
- Strip WS_EX_TOPMOST from any host window before requesting its
controller; the lazy-topmost gate re-pins all three once ready.
- Serialize controller creation (one in-flight at a time) to avoid
E_INVALIDARG from concurrent CreateCoreWebView2Controller calls on
the same environment.
- Rotate past a persistently failing host so it cannot starve siblings.
- Harden LOCALAPPDATA resolution with SHGetKnownFolderPath fallback.
- Increase watchdog restart delay to 2s for user-data-folder lock drain.
- Add diagnostic logging (traymenu-diag.log) for WebView2 init states.
fanlusky