fix(ime): don't force the soft keyboard up when a hardware keyboard is attached - #266
Open
GlassOnTin wants to merge 2 commits into
Open
fix(ime): don't force the soft keyboard up when a hardware keyboard is attached#266GlassOnTin wants to merge 2 commits into
GlassOnTin wants to merge 2 commits into
Conversation
…s attached showIme() passes SHOW_FORCED unconditionally. That flag is documented to keep the IME open "until the user explicitly closes it", which overrides the platform's own rule that a usable hardware keyboard suppresses the soft one. The visible effect is on devices where a real keyboard is the primary input: reported on a Meta Quest 3 with a Bluetooth keyboard, where every keypress raised the on-screen keyboard over the terminal. Passing no flags in that case hands the decision back to the platform, which still honours the user's "show virtual keyboard" setting for anyone who wants both. hardKeyboardHidden is part of the test rather than Configuration.keyboard alone: a folded or undocked device reports KEYBOARD_QWERTY while the keys are physically unreachable, and there the soft keyboard is the only way to type, so SHOW_FORCED still earns its keep. The policy is a top-level imeShowFlags(keyboard, hardKeyboardHidden) rather than a method reading resources.configuration, so it can be tested from plain constants without a Context. ImeShowFlagsTest covers all four combinations and was confirmed to fail against an unconditional SHOW_FORCED. Not verified on a Quest 3 — I don't have one. The mechanism is documented and matches the reported symptom, but whether it is the whole cause on that device is unconfirmed.
GlassOnTin
added a commit
to GlassHaven/Haven
that referenced
this pull request
Aug 8, 2026
Four issues from this week's reports, plus a build-infrastructure fix that main needed. #515 — toolbar arrows latching into a dead state after a hold, and the soft keyboard not coming back after backgrounding. Two independent latches for the first; core:toolbar gained its first test source set, which is why the bug shipped in the first place. #511 — the virtual keyboard covering the session on a Meta Quest 3 with a physical keyboard attached. Unverified on that hardware; the reporter has been asked to confirm. The termlib half is upstreamed as connectbot/termlib#266. #516 — Campbell, Modern Dark and Modern Light colour schemes, transcribed from the upstream projects rather than approximated. #514 — release pages now explain the two APK flavours instead of leaving six filenames unexplained. Also carried: mirror fallbacks for the pinned native sources. code.videolan.org went dark on 2026-08-08 and took down both this repo's CI and the F-Droid build of 5.87.1 at the x264 clone. Mirrors are fetched by commit, so the existing pin verification is unchanged and they buy availability rather than trust.
CI runs spotlessKotlinCheck, which Haven's fork does not, so this only showed up here. Single-expression function on one line.
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.
showIme()passesSHOW_FORCEDunconditionally. That flag is documented to keep the IME open "until the user explicitly closes it", which overrides the platform's own rule that a usable hardware keyboard suppresses the soft one.The visible effect is on devices where a real keyboard is the primary input. This came in as a bug report against a Meta Quest 3 with a Bluetooth keyboard attached: every keypress raised the on-screen keyboard over the terminal session.
Passing no flags in that case hands the decision back to the platform, which still honours the user's "show virtual keyboard" setting for anyone who genuinely wants both on screen.
Why
hardKeyboardHiddenis in the testChecking
Configuration.keyboardalone isn't enough — a folded or undocked device reportsKEYBOARD_QWERTYwhile the keys are physically unreachable. There the soft keyboard is the only way to type, soSHOW_FORCEDstill earns its keep.Shape
The policy is a top-level
imeShowFlags(keyboard, hardKeyboardHidden)rather than a method readingresources.configuration, so it can be tested from plainConfigurationconstants without aContext.ImeShowFlagsTestcovers all four combinations, and I confirmed each assertion fails against an unconditionalSHOW_FORCEDbefore trusting it.What I haven't verified
I don't have a Quest 3. The mechanism is documented and matches the reported symptom exactly, but whether it's the whole cause on that device is unconfirmed — I've asked the reporter to test it. Happy to hold this until they come back if you'd rather.
Carried downstream in the Haven fork, where it ships in the next release.