Repository navigation
fix(ime): docked choice survives keyboard switches — self-healing mode restore, engine re-entry guard, unbind cleanup - #74
Merged
Conversation
…e restore, engine re-entry guard, unbind cleanup (#73) Heide (v0.1.21): "The IME still starts in float mode, then you have to tap on dock. Then it's fine unless you switch keyboards." Not a v0.1.22 regression — v0.1.22's IME changes are output batching + force-show; this is the #64 mode-remember machinery, which has three lifecycle holes: - onCreateInputView can run again on a LIVE instance (configuration change; some OEM IME-switch flows keep the service alive). On re-entry createEngine() built a SECOND engine (the first kept its dasher_frame loop — both submitting into the same canvas), and a stale floating=true made the posted restore early-return inside enterFloatingMode(): a dead overlay canvas presented as floating over a full-height docked root. Tap Dock → clean; switch keyboards → the cycle repeated. - No onUnbindInput cleanup: a surviving service left the overlay hovering over the next keyboard. - exitFloatingMode early-returned when floatingView was null — a swallowed removeView failure (Samsung overlay quirks, cf. #46) stranded a dead overlay over every subsequent show. Fixes: - createEngine: re-entry guard — the engine is per-process by design (#53/#56); a second one leaked the first. - Posted restore: self-heal — if floating, exitFloatingMode(persist= false) FIRST, then evaluate the saved preference, so every keyboard show converges to the persisted mode regardless of view recreation. - onUnbindInput: exit floating without persisting (the saved mode stays the user's deliberate choice; it is re-evaluated on the next show). - exitFloatingMode: never early-return on a missing overlay window — mode state and docked layout are restored regardless; removeView failures now log. Manual verification still needed on Heide's device (Samsung/Android 16) to confirm which path she hits; all three are hardened. Signed-off-by: will wade <willwade@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #73.
Heide (testing v0.1.21, before v0.1.22): "The IME still starts in float mode, then you have to tap on dock. Then it's fine unless you switch keyboards."
Not a v0.1.22 regression — v0.1.22's IME changes are output batching + force-show. This hardens #64's mode-remember machinery, which has three lifecycle holes found by inspection:
onCreateInputViewre-entry on a live instance (config change; OEM IME-switch flows that keep the service alive):createEngine()built a second engine — the first kept itsdasher_frameloop, both submitting into the same canvas — and a stalefloating=truemade the posted restore early-return insideenterFloatingMode(), presenting a dead overlay canvas as "floating" over a full-height docked root. Tap Dock → clean; switch keyboards → repeats. This matches the report verbatim.onUnbindInputcleanup — a surviving service left the overlay hovering over the next keyboard.exitFloatingModeearly-returned onfloatingView == null— a swallowedremoveViewfailure (Samsung overlay quirks, cf. Floating window drag: horizontal moves opposite on Samsung (Galaxy Fold 5) — gravity + y-axis inversion #46) stranded a dead overlay over every subsequent show.Changes (single file, +51/−4)
createEngine(): re-entry guard — the engine is per-process by design (IME can't type after visiting the main app — static output listener nulled by MainActivity #53/Per-engine-instance listeners instead of process-wide statics — the recurring #53 class #56)if (floating) exitFloatingMode(persist = false)before evaluating the saved preference, so every keyboard show converges to the persisted mode regardless of view recreationonUnbindInput(): exit floating without persisting (saved mode stays the user's deliberate choice)exitFloatingMode(persist): never early-returns on a missing overlay window;removeViewfailures now logTesting
:app:assembleDebug+:app:testDebugUnitTestgreen locallyGiven #71's human review is pending, happy to fold this into the same review session.