@cplieger/web-terminal-ui 2.1.1 → 2.1.3

package/css/02-app.css

@@ -57,15 +57,19 @@
 }
 
 .term-input {
-  /* Keep the input INSIDE the viewport (not at left:-9999px) — iOS
-   * Safari is increasingly strict about not opening the virtual
-   * keyboard for off-screen inputs, especially during heavy DOM
-   * mutations like a streaming agent turn. A 1×1 fully-transparent
-   * pinned-bottom input is "visible enough" for iOS without being
-   * tappable or perceptible to the user. opacity:0 + size:1px hides
-   * it visually; pointer-events:none makes sure stray taps don't
-   * land on it (programmatic focus() still works). */
-  position: fixed;
+  /* The hidden keyboard target. position:absolute (NOT fixed) so it lives in
+     the terminal's scroll/content coordinate space alongside .composition-view
+     and .pred-cursor: composition.positionCompositionView() moves it to the
+     cursor row, and because .term is pinned to the visual viewport (viewport.ts)
+     the textarea always sits at the VISIBLE cursor, above the keyboard, which is
+     where iOS wants the focused input so it does not scroll the page. As
+     position:fixed it was placed at the cursor's content offset in viewport
+     space, so once output had scrolled it landed off-screen / behind the
+     keyboard, and focusing it made iOS scroll the page up to reveal it (the
+     content jump). Kept on-screen and 1x1 / opacity:0 so iOS still opens the
+     keyboard for it; pointer-events:none so taps fall through to the scroll
+     surface (programmatic focus() still works). */
+  position: absolute;
   inset-block-end: 0;
   inset-inline-start: 0;
   width: 1px;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cplieger/web-terminal-ui",
-  "version": "2.1.1",
+  "version": "2.1.3",
   "type": "module",
   "description": "Reference touch-first browser UI for @cplieger/web-terminal-engine: textarea input model, mobile key toolbar, context menu, IME, predictive echo, viewport/keyboard-inset handling, and CSS. One mount() call.",
   "license": "GPL-3.0-or-later",

package/src/composition.ts

@@ -141,8 +141,12 @@ export function positionCompositionView(): void {
   compositionView.style.top = `${top}px`;
   compositionView.style.height = `${cellH}px`;
   compositionView.style.lineHeight = `${cellH}px`;
-  // Textarea piggy-backs on the cursor position so iOS scroll-into-
-  // view targets the cursor area instead of jumping to top-left.
+  // The textarea is position:absolute in the same scroll/content space as the
+  // composition view (see the .term-input CSS note), so the cursor's content
+  // coordinates place it at the cursor row directly. Because .term is pinned to
+  // the visual viewport (viewport.ts), that keeps the textarea at the VISIBLE
+  // cursor, above the keyboard — where iOS wants the focused input so it doesn't
+  // scroll the page to reveal it.
   textarea.style.left = `${left}px`;
   textarea.style.top = `${top}px`;
   textarea.style.height = `${cellH}px`;

package/src/viewport.ts

@@ -61,15 +61,28 @@ export function init(opts: {
   if (window.visualViewport) {
     const vv = window.visualViewport;
     const onChange = (): void => {
-      const inset = Math.max(0, Math.round(window.innerHeight - vv.height));
-      termWrap.style.bottom = inset > 0 ? `${inset}px` : "";
-      // Expose viewport geometry as CSS vars so fixed chrome stays in view:
-      // --kb-inset lifts the bottom banner above the keyboard; --vv-top lets
-      // the top toolbar counter iOS shifting content up to reveal the
-      // bottom-pinned input (otherwise the toolbar scrolls off the top).
+      // Pin the terminal's fixed box to the exact region the VISUAL viewport
+      // occupies inside the layout viewport. On iOS the soft keyboard shrinks
+      // (and can offset) the visual viewport WITHOUT resizing the layout
+      // viewport — interactive-widget=resizes-content is not honored on iOS
+      // Safari — so a `position: fixed; inset: 0` terminal keeps the full-screen
+      // height (keyboard overlaying the bottom) while iOS scrolls the focused
+      // input into view and shifts the fixed box up, sliding the output and
+      // prompt behind the keyboard (the "content jumps up, hidden until I
+      // scroll" symptom). Driving top AND bottom from visualViewport keeps the
+      // terminal exactly over the visible area in every browser, so nothing is
+      // left behind the keyboard for iOS to scroll to.
+      const offsetTop = Math.max(0, Math.round(vv.offsetTop));
+      const bottomInset = Math.max(0, Math.round(window.innerHeight - vv.offsetTop - vv.height));
+      termWrap.style.top = offsetTop > 0 ? `${offsetTop}px` : "";
+      termWrap.style.bottom = bottomInset > 0 ? `${bottomInset}px` : "";
+      // Expose the same geometry as CSS vars for the sibling fixed chrome:
+      // --kb-inset lifts the bottom banner above the keyboard; --vv-top lets the
+      // top key toolbar follow the visual viewport's offset (otherwise it
+      // scrolls off the top when iOS shifts the layout up).
       const root = document.documentElement.style;
-      root.setProperty("--kb-inset", `${inset}px`);
-      root.setProperty("--vv-top", `${Math.max(0, Math.round(vv.offsetTop))}px`);
+      root.setProperty("--kb-inset", `${bottomInset}px`);
+      root.setProperty("--vv-top", `${offsetTop}px`);
       startTransition();
     };
     vv.addEventListener("resize", onChange);