URL
https://ionicframework.com/docs/developing/keyboard
Issue Description
The page covers inputmode, enterkeyhint, dark mode, the accessory bar and lifecycle events, but never says what the keyboard does to the viewport. In a mobile browser or PWA, Chrome and current Firefox shrink the visual viewport and leave the layout viewport at full height, so anything anchored to the bottom of the page stays where it was and the keyboard is drawn over it. This affects ion-fab, ion-footer and ion-tab-bar.
That is intended behavior, and refer to #26702 for the reasoning on why we do not resize the layout viewport by default. The problem is that the page never tells developers this is the model, nor how to opt into the alternative, so it keeps getting refiled: #7013 (2016), #26702 (2023), #29765 (2024). Three reports over eight years for behavior that one documented meta key configures.
Suggested addition, as a section near Keyboard Lifecycle Events:
- The keyboard shrinks the visual viewport, not the layout viewport, in browsers and PWAs, so bottom-anchored elements do not move.
- Apps that want the layout to move can add
interactive-widget=resizes-content to the viewport meta tag, with the caveat that footers and tab bars then move above the keyboard too. Verified on Chrome 133 and Firefox 155.
100dvh does not account for the on-screen keyboard and is not an alternative. Worth saying outright, because it is the first thing people reach for.
- Capacitor apps should use the Keyboard plugin's resize modes rather than the meta tag.
Files
docs/developing/keyboard.mdx (v9)
versioned_docs/version-v8/developing/keyboard.mdx
URL
https://ionicframework.com/docs/developing/keyboard
Issue Description
The page covers
inputmode,enterkeyhint, dark mode, the accessory bar and lifecycle events, but never says what the keyboard does to the viewport. In a mobile browser or PWA, Chrome and current Firefox shrink the visual viewport and leave the layout viewport at full height, so anything anchored to the bottom of the page stays where it was and the keyboard is drawn over it. This affectsion-fab,ion-footerandion-tab-bar.That is intended behavior, and refer to #26702 for the reasoning on why we do not resize the layout viewport by default. The problem is that the page never tells developers this is the model, nor how to opt into the alternative, so it keeps getting refiled: #7013 (2016), #26702 (2023), #29765 (2024). Three reports over eight years for behavior that one documented meta key configures.
Suggested addition, as a section near Keyboard Lifecycle Events:
interactive-widget=resizes-contentto the viewport meta tag, with the caveat that footers and tab bars then move above the keyboard too. Verified on Chrome 133 and Firefox 155.100dvhdoes not account for the on-screen keyboard and is not an alternative. Worth saying outright, because it is the first thing people reach for.Files
docs/developing/keyboard.mdx(v9)versioned_docs/version-v8/developing/keyboard.mdx