Repository navigation
IME: keyboard starts in float mode after switching keyboards — docked choice doesn't survive (Heide, pre-v0.1.22) #73
Description
Heide (before testing v0.1.22, i.e. on v0.1.21 which introduced #64's mode persistence):
"Oh yeah, I forgot about the docking issue. The IME still starts in float mode, then you have to tap on dock. Then it's fine unless you switch keyboards."
Not fixed by v0.1.22 (its IME changes are output batching + force-show only). Lifecycle holes in the #64 restore machinery, found by inspection:
onCreateInputViewcan run again on a LIVE instance (configuration change; some OEM IME-switch flows keep the service alive):createEngine()builds a second engine (the first keeps itsdasher_frameloop — both submit into the same canvas), and a stalefloating=truemakes the posted restore early-return insideenterFloatingMode()— a dead overlay canvas presents as "floating" over a full-height docked root. Tap Dock → clean; switch keyboards → repeats.- No
onUnbindInputcleanup — a surviving service leaves the overlay hovering over the next keyboard. exitFloatingModereturns early whenfloatingView == null— a swallowedremoveViewfailure strands a dead overlay over every subsequent show.
Manual repro needed on Heide's device (Samsung, Android 16) to confirm which path she hits; the fix hardens all three.
Activity
willwade commentedon Oct 24, 2026
Round 3 update after Heide's v0.1.23 test ("still starts in float mode… this time it doesn't stay in docked mode when you bring the keyboard up again").
The v0.1.23 fix (#74) did not fix her device. A full reproduction attempt on an API 35 emulator (edge-to-edge enforced) could not reproduce the float restart: the docked keyboard lays out correctly across show/hide cycles and IME switches, and the pref state machine behaves as designed. The trigger appears to be Samsung/OneUI-specific (Android 16 tablet).
Two outcomes from the session:
ime_mode_restore/ime_float_enter/ime_float_exitanalytics events (opt-in) with every decision input — if float still appears for her on this build, her next session identifies the exact path.setDockedHeightcreatedFrameLayout.LayoutParamswith no gravity, which defaults the docked root to TOP|START in the IME decor. Every current layout path re-docked it in testing, but it was never correct — now explicitGravity.BOTTOM.Also noting her positive signal for the release notes: "the letters are not right on top of your cursor… you have time to look until the nodes get closer… better than the last version" — consistent with the #59 Android-16 Samsung canvas-offset fix landing.
fix(ime): review loop 1 — pre-heal floating capture, schema'd events,…
feat(ime): 'Always start docked' setting + float-mode diagnostics (#73 …
fix(ime): stuck 'Preparing Dasher' overlay after view recreation — th…
willwade commentedon Oct 25, 2026
Closing the loop: the root cause of all four rounds of 'float mode' reports was the stuck loading overlay (#76, fixed in v0.1.25), not the mode preference. The #75 always-docked setting and ime_mode_restore diagnostics remain as safety nets — reopen with fresh ime_mode_restore data if any float symptom survives v0.1.25.
fix(ime): docked keyboard was full-screen (LayoutParams stamped over)…