Repository navigation
IME: stuck 'Preparing Dasher' overlay after view recreation — the 'big float-like window you can't type on' (Heide, v0.1.24, MuMu) #76
Description
Heide, on v0.1.24 (MuMu emulator):
"It's still doing the same thing, unfortunately. It still starts in float mode. Well, come to think of it, it doesn't even do that. It starts with a big float LIKE window, but you can't type on it. You have to tap on Float first and then Dock. I took a small video, so you can see what it does."
(Video incoming via Google Drive.)
Root cause — a regression from #74, reproduced and fixed. When onCreateInputView runs again on a LIVE service instance (configuration change: rotation, fold, MuMu's freely-resizable window; OEM IME-switch flows that keep the service alive), the recreated view tree builds a fresh "Preparing Dasher" loading overlay — visible by default. But createEngine() returns at #74's engine re-entry guard BEFORE the line that hides the overlay, so the opaque overlay covers the canvas forever: a big, dead, overlay-looking panel. Untypeable, and the Float/Dock buttons sit outside the overlay — which is why "tap Float then Dock" appeared to revive it.
This re-explains the entire #73 timeline — "still starts in float mode / fine unless you switch keyboards / doesn't stay docked" were all this dead-canvas state, never the mode preference. The timing fits: v0.1.23 shipped the #74 guard, exactly when "doesn't stay docked when you bring the keyboard up again" appeared.
Repro (API 33 emulator, MuMu's Android generation): rotate with the keyboard up → same-instance view recreation → guard-path restore in 0.3s (vs 3–4s for a full create) → screenshot shows zero colorful canvas pixels — uniform overlay. Post-fix on the identical repro: canvas renders (500 colorful px) and responds to zoom (106 px change during a drag).
Fix in the attached PR. The #75 always-docked toggle and mode diagnostics remain useful independently.
Activity
willwade commentedon Oct 25, 2026
Fixed in #77, shipped as v0.1.25. Heide's test ask: resize the MuMu window / rotate mid-typing — the keyboard should stay alive with no Float→Dock ritual needed.
fix(ime): docked keyboard was full-screen (LayoutParams stamped over)…
willwade commentedon Oct 28, 2026
Round 2, and this time with the mechanism: E2E testing on the API 35 emulator revealed the IME framework stamps its own LayoutParams over the docked root's after attaching it — so the height/gravity set at view creation were silently discarded and the "docked" keyboard laid out full-screen, top-anchored (measured: 1080x2272 at [0,0]). That is a giant, overlay-looking, app-swallowing keyboard — matching every description in this issue's history, including "big float LIKE window you can't type on". It also explains why the earlier Gravity.BOTTOM fix "verified" on the API 33 emulator — that layout path re-docks on its own, hiding the stamping.
Fixed in #78 (v0.1.26): the docked height is re-applied after attachment (and re-asserted on every keyboard show), verified pixel-level in portrait + landscape, through rotations, resizes, and IME switches. Heide's test ask for v0.1.26: just use it — open the keyboard in any app, rotate/resize, switch keyboards; it should stay docked at the bottom and never present as a full-screen panel.