Claude
544c599a5a
Both composers are position:sticky;bottom:0, which pins them to the bottom of the *layout* viewport. A phone keyboard does not shrink that viewport -- it only covers it -- so the first tap on the input left the box sitting behind the keyboard. Tapping back and focusing again appeared to work only because the page had been scrolled during the first attempt, so the browser's scroll-into-view landed somewhere else. Two engines, two halves: - Chromium honours interactive-widget=resizes-content on the viewport meta, which makes the layout viewport shrink when the keyboard opens, so 100dvh and sticky bottoms account for it on their own. - iOS Safari ignores that flag and only shrinks the visual viewport, so measure the covered height from visualViewport and publish it as --kb-inset; the composers offset their sticky bottom by it. On browsers that already resized the layout viewport the measurement is ~0, so the same rule is a no-op there instead of a double lift. The pages also gain a matching bottom margin so the last beat can still be scrolled clear of a lifted composer. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011BC7Dsg4gSQm3NLcZcG5SK
33 lines
1.5 KiB
JavaScript
33 lines
1.5 KiB
JavaScript
// Mobile virtual keyboards vs. the bottom-sticky composers.
|
|
//
|
|
// A phone keyboard covers the bottom of the screen without shrinking the
|
|
// layout viewport, so `position: sticky; bottom: 0` keeps pinning the composer
|
|
// to a bottom edge the user can no longer see — tap the box and it vanishes
|
|
// behind the keyboard. Chromium can be told to shrink the layout viewport
|
|
// instead (`interactive-widget=resizes-content` on the viewport meta in
|
|
// index.html), which fixes it there. iOS Safari ignores that flag and only
|
|
// ever shrinks the *visual* viewport, so measure the overlap ourselves and
|
|
// publish it as --kb-inset for the composers to lift by.
|
|
//
|
|
// Where the browser did resize the layout viewport, window.innerHeight shrank
|
|
// along with it and this measures ~0 — the same CSS is a no-op there rather
|
|
// than a double lift.
|
|
|
|
const MIN_KEYBOARD = 80 // px — below this it's browser chrome, not a keyboard
|
|
|
|
export function trackKeyboardInset() {
|
|
const vv = window.visualViewport
|
|
if (!vv) return
|
|
const apply = () => {
|
|
// Pinch-zoom shrinks the visual viewport too, and that is not a keyboard.
|
|
const covered = vv.scale > 1.01 ? 0 : window.innerHeight - vv.height - vv.offsetTop
|
|
const inset = covered > MIN_KEYBOARD ? Math.round(covered) : 0
|
|
document.documentElement.style.setProperty('--kb-inset', `${inset}px`)
|
|
}
|
|
// resize fires as the keyboard animates in; scroll fires as the page pans
|
|
// under a keyboard that is already up, which moves offsetTop.
|
|
vv.addEventListener('resize', apply)
|
|
vv.addEventListener('scroll', apply)
|
|
apply()
|
|
}
|