iPad layout remains horizontally offset after dismissing software keyboard

Summary

On iPad, focusing the bottom composer opens the software keyboard. After dismissing the keyboard, Hermes WebUI can remain horizontally misaligned instead of returning to its original three-column layout: part of the right workspace panel remains exposed and the left side appears retracted or squeezed.

The problem was reproduced by the reporter across multiple iPad browsers. The equivalent phone layout recovers correctly.

Reproduction

1. Open Hermes WebUI on an iPad in a browser.
2. Use a viewport wide enough that the WebUI is using its tablet/desktop panel layout rather than the <=640px phone layout.
3. Focus the composer at the bottom of the chat so the iPad software keyboard opens.
4. Dismiss the software keyboard.

Expected behavior

The layout returns to its pre-keyboard horizontal alignment. The left sidebar, center conversation, and right workspace panel occupy their original positions and widths.

Actual behavior

The page can remain horizontally offset after keyboard dismissal. A portion of the right workspace panel is exposed and the left side looks retracted/squeezed. Reloading restores the layout.

Suspected cause

The existing visualViewport recovery path is phone-width gated (<=640px). iPad uses a wider tablet/desktop layout, so the browser can leave a page-level horizontal offset after keyboard geometry changes without receiving the same repaint/reset recovery used by phones.

Proposed direction

• Extend the existing viewport-reflow recovery to touch-primary software-keyboard viewports, including wide iPads.
• Clear only page-level horizontal offset while preserving the current vertical position.
• Apply the one-frame layout repaint guard outside the phone-only media query.
• Clip root/layout horizontal overflow with overflow-x: clip, not hidden, to avoid creating a competing vertical scroll container.
• Keep ordinary desktop visual-viewport events out of the workaround.

Design concerns / alternatives to review

• window.scrollTo(0, window.scrollY) is an imperative browser workaround. It should remain scoped to phone/touch-keyboard viewports and run only on viewport geometry events.
• Touch media queries are an imperfect proxy for “an iPad software keyboard changed geometry,” especially on hybrid devices with a fine pointer. The existing _isTouchKeyboardViewport() policy intentionally excludes co-existing fine-pointer setups; maintainers may prefer a geometry/state-based keyboard lifecycle signal if there is a reliable cross-browser one.
• A GPU-promotion repaint (translateZ(0)) is also a workaround. It should be transient and removed on the next animation frame.
• Root/layout clipping prevents the visible symptom but must not replace resetting the stale page offset.
• Automated DOM/Node tests can prove the application recovery behavior, but cannot prove iPadOS/WebKit event delivery. Physical-iPad validation remains the source of truth for the browser behavior.

Environment / scope

• Device class: iPad
• Trigger: opening and dismissing the software keyboard from the bottom composer
• Browsers: reported across multiple iPad browsers
• Phone layout: reported working
• Desktop with mouse/trackpad: should remain unaffected