Mobile UI Send Button not visible #1775

Activity

1. github-project-automation

   added this to roadmapon Sep 9, 2026
2. github-project-automation

   moved this to Backlog in roadmapon Sep 9, 2026
3. cruzanstx commented on Oct 13, 2026

   

   cruzanstx

   on Oct 13, 2026

   More actions

   Additional reproduction: Android Chrome web composer clipped below the visible viewport

   Corroborating the missing/partially obscured Start/Send action reported here. Related viewport fix: #1882.

   Environment

   • Self-hosted Happy web client built from upstream commit 99f415fa using Dockerfile.webapp.
   • Expo web output is single.
   • Physical Android phone using Chrome. Exact Android/Chrome versions were not collected.
   • Machine online; session creation completed successfully with claude-opus-5-5. This is separate from model selection or daemon availability.

   Reproduction

   1. Open the Happy web client in Android Chrome with its address bar visible.
   2. Open Start New Session and select an online machine and a valid directory.
   3. Enter a short draft, then dismiss the keyboard.
   4. Observe the composer at the bottom of the screen. Also inspect the composer in an existing chat and a new pending-chat tab.

   Actual behavior

   The top of the draft field is visible, but the lower composer/action row extends below the visible browser area. Start/Send cannot be reached. Physical-phone screenshots show this on Start New Session, an existing online chat, and the pending-chat screen. A nonempty draft confirms this is not the expected microphone-only state of an empty composer.

   Expected behavior

   The whole composer and its Start/Send action should remain within the visible viewport, including when browser chrome is visible and after keyboard dismissal. Pending chats should retain their usable composer during session startup.

   Related upstream work

   PR #1882 identifies a relevant shared sizing rule in sources/theme.css:

   html.happy-app-zoomed body {
       height: calc(100vh / var(--happy-app-zoom));
   }

   Its proposed 100dvh override accounts for mobile browser toolbars. At the time of this report, current upstream main still contains the 100vh rule without that override, and #1882 is not merged. This appears to be the same viewport-sizing family; we have not run that PR on the affected physical phone to establish that it fully resolves these composer cases.

   Local workaround and verification

   A local web-only workaround sizes #root to window.visualViewport.height, updates it on window/VisualViewport resize, falls back to window.innerHeight, and includes 100dvh CSS fallback. It avoids reflow during pinch zoom and ignores zero-height events.

   Important build detail: with Expo web.output: "single", changes to app/+html.tsx were absent from the exported artifact. The workaround had to run from the web application startup path; we verified it was embedded in the exported JavaScript before deployment.

   Verification completed:

   • Four focused regression tests passed: visible-height sizing, resize transitions, pinch-zoom/zero-height protection, and fallback resizing.
   • Nine authenticated Chromium mobile-emulation checks passed across Start New Session, existing chat, and pending chat. Both bounding-box visibility and DOM hit-testing passed. Sizes included 384×720, 412×760, 384×400, and 720×384 for the first two surfaces; the pending-chat check used 384×720.
   • An explicitly synthetic visible/layout-viewport mismatch used an 800px layout viewport and a 620px visible viewport: the action bottom moved from 780px (clipped) to 600px (visible) with the workaround.

   Limitations: reduced-height emulation is not a real Android soft keyboard. Post-fix confirmation on the originally affected physical phone remains pending. Full application typechecking already failed on unrelated upstream diagnostics; it is not reported as green.

   Please include the new-session and chat composers in the acceptance coverage for #1882, in addition to the bottom navigation bar.