Dismissing the software keyboard changes the visible area

What it is

Once a hardware keyboard is attached, the system usually dismisses the on-screen keyboard, and the visible area suddenly grows: content that was covered or pushed up settles back, a bottom bar reappears, and the scrollable length shortens. Unplug the keyboard, or focus a field that still needs the software keyboard, and the visible area shrinks again. This entry is about that rise and fall of height budget, not about how focus walks, and not about what shortcuts are named. Occlusion when a software keyboard appears is a related but separate problem. The subject here is the strip of screen that comes back when the keyboard leaves, and the strip that is taken again when it returns.

Why it happens

Tablet layout is measured against the current window minus the inset occupied by the software keyboard. The keyboard takes the lower half; the app lifts fields into the remaining viewport. On dismiss, the inset goes to zero and the viewport grows. If layout was measured only once, dismiss leaves a band of space sized for “keyboard present,” or leaves already-lifted content in the top half with an empty bottom. The reverse path: unplug, tap a field, the software keyboard rises again; a submit button that does not move up is covered by the new keyboard. Attached-keyboard mode can still raise a short panel for emoji, dictation, or handwriting, so visible height is a continuous change, not two bins of “on / off.” Scroll position stored against “content height with keyboard” jumps when the keyboard leaves, and the document looks as if it moved by itself.

Studying it

Watch the same form under keyboard attached, keyboard unplugged, and keyboard attached with an emoji panel still raised. Check whether the field, the submit control, and the bottom toolbar stay in the visible area, and whether scroll jumps without a user gesture.

Independent variables: whether layout listens to keyboard-inset changes, whether submit is pinned to the window bottom or to the visible bottom, whether scroll restore uses content offset or viewport offset. Dependent variables: count of required controls occluded, height of the empty band after dismiss, jump in scroll pixels, whether submit needs a manual scroll.

Do not only capture two static frames of “keyboard / no keyboard.” Record the connect and disconnect instants; the jump lives in the transition. Desktops have no software-keyboard inset; desktop window resize is not a proxy.

Where it stops holding

If the app itself keeps a software keyboard up (handwriting- or emoji-first input), attaching a hardware keyboard will not dismiss that region, the viewport change does not occur, and focus plus shortcuts still have to work. Full-screen drawing or games treat the software keyboard as interference; after a hardware keyboard attaches, keep the canvas full height rather than shrinking it for an inset that will never appear. In split-screen the software keyboard may belong to one window only; the other window’s viewport should not jump with it. A hardware keyboard with a touch bar or function row may take another thin inset; that is a different hardware occupancy, not the same reflow as software-keyboard dismiss.

Applying it

• Listen to keyboard safe-area changes and lay out the bottom bar and submit against current visible height. Do not measure once against the full device height.
• After dismiss, let lifted content settle and drop the spacer reserved for the keyboard. Do not write a “keyboard-present” scroll offset back into a taller viewport.
• A short panel (emoji, candidates, handwriting) can still appear with a hardware keyboard; pin primary bottom actions to the visible bottom, not to the physical bottom of the glass.
• Verify by attaching a keyboard: submit should be visible without scrolling. Unplug, focus a field: the button should remain above the keyboard. An empty band or a covered button means the visible area is not tracking the rise and fall.

Related

• Within the group: K3.04.1 An attached keyboard requires full keyboard navigation · K3.04.3 Shortcuts should match the desktop ones people already know
• Adjacent: C6.06 Soft Keyboards and Screen Occupancy · K3.03 Fold-state Transitions · K3.05 Split-screen and Multitasking
• Search terms: software keyboard inset · viewport resize · keyboard dismissal