fix(mobile): expanded HTML pages start below the header on iOS#23797

open4
main
GitHub fork: fix/mobile-html-render-under-header
opened7d agobyCClaudesaul
View on GitHubTwo-way sync enabledPR last imported 1d ago

On iOS, expanding an agent's HTML page from a thread opens it with its top under the header and a gap below it. If the page fits the screen, scrolling can't bring the top back. The full-screen WebView extends under the translucent header, and react-native-webview leaves contentInsetAdjustmentBehavior at never. The automaticallyAdjustContentInsets prop it was getting does nothing for WKWebView.

Now the full-screen WebView uses automatic, so iOS insets the page below the header and above the home indicator. Pages shown inline in the thread keep never. Small fix for an obvious bug.

Checked on an iPhone 18 Pro Max simulator (iOS 27) against a local dev server, with an agent-rendered page of three stacked cards. Each clip expands the page from the thread, pulls down, then swipes up a little. Before, card A opens cut off under the header, shows only during the pull-down bounce, and snaps back under it. After, it opens below the header and settles there. Not checked on a device or on Android, where the prop doesn't apply.

Checks

20 successful · 8 skipped
All checks passed
914dacb

Added 1 commit

  • fix(mobile): expanded HTML pages start below the header on iOS935e101
Synced from GitHub

Review in Change Stack →

No actionable comments were generated in the recent review.

External image Recent review info
External image Run configuration
External image Commits

Reviewing files that changed from the base of the PR and between 935e1015c9bdb312cd3f9378e352657ece6429b8 and 914dacb629aa77d25039fedebb04a571d98ac8d5.

External image Files selected for processing: 1
  • apps/mobile/src/features/threads/HtmlRenderWebView.tsx
External image Files skipped from review as they are similar to previous changes: 1
  • apps/mobile/src/features/threads/HtmlRenderWebView.tsx

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 7 remain after this review.

Walkthrough

A comment in HtmlRenderWebView.tsx explains that expanded pages extend under the iOS header and need native safe-area insets. No runtime behavior changed.

Changes: Expanded-page safe-area note

Layer / File(s)Summary
Document safe-area inset requirement
apps/mobile/src/features/threads/HtmlRenderWebView.tsx
A comment explains that expanded pages extend under the iOS header and need native safe-area insets.

Priority: External image Normal

Estimated code review effort: 1 (Trivial) | ~2 minutes

Change: Bug fix

Suggested reviewers: juliusmarminge

Merge Risk: External image Minimal · up to 914da

No actionable issue is established that should block merging. Native-device verification remains a useful follow-up.

Pre-merge checks: Passed 4
Check nameStatusExplanation
Title checkPassedThe title clearly identifies the mobile iOS fix and the affected expanded HTML pages. It is concise and uses a conventional commit format.
Description checkPassedThe description explains the iOS problem, the WebView change, the scope decision, focused simulator verification, observed before-and-after behavior, and untested platforms. It does not use the templa…
Linked Issues checkPassedCheck skipped because no linked issues were found for this pull request.
Out of Scope Changes checkPassedCheck skipped because no linked issues were found for this pull request.
Full details: Description check

Explanation

The description explains the iOS problem, the WebView change, the scope decision, focused simulator verification, observed before-and-after behavior, and untested platforms. It does not use the template headings, but it includes the required information and is sufficiently complete.

Finishing Touches
🧪 Generate unit tests (beta)
  • Create a new PR
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Comment @coderabbitai help to get the list of available commands.

Added 2 commits

  • Merge remote-tracking branch 'github/main' into takeover-237975ff38fa
  • refactor(mobile): shorten expanded HTML inset explanation7358489

Note

Written by gpt-6.1-sol on behalf of Maria

Kept @Claudesaul's implementation and commit, merged current github/main without rebasing, and shortened the explanatory comment. The final diff is one prop replacement plus one comment in HtmlRenderWebView.tsx: expanded pages use automatic; inline pages retain never. No behavior from the original diff was dropped.

Verification at 7358489c14db3219f2adbb8e26833c456c74ddcf:

  • Blacksmith vp run check:changed passed formatting, lint, both knip passes, and affected mobile/scripts typechecks.
  • Existing attachment presentation and shared HTML-render suites passed: 20 tests.
  • All reported GitHub CI checks passed or were skipped by their normal gates.
  • Two independent scoped code reviews found no actionable issues. CodeRabbit reported success but skipped its new review because the organization review limit was reached.

Unverified: fresh native iOS before/after captures, physical devices, and Android runtime behavior. This Linux VM cannot run WKWebView; Playwright/Chrome would exercise a different client and cannot prove UIKit safe-area adjustment. The original PR's simulator evidence remains in the description and is prior contributor evidence, not a new reproduction. Please confirm expanding a short HTML page starts below the header and returning preserves the inline page before merging.

No new test files, labels, or unrelated code changes. The temporary dev server and Blacksmith worker were stopped.

Added 1 commit

  • chore: merge main into mobile html inset fix914dacb

Note

Written by gpt-6.1-sol on behalf of Maria

Merged current github/main into the existing head without rebasing: 914dacb629aa77d25039fedebb04a571d98ac8d5. Resolved the comment-only conflict while retaining both sides' behavior. Main independently landed the same inset fix in #25765, so the remaining diff is one explanatory comment. No labels changed manually.

Blacksmith passed vp run check:changed (format, lint, both knip passes, affected mobile/scripts typechecks) and 20 existing attachment-presentation/HTML-render tests. Two independent scoped reviews approved this head with no actionable findings. GitHub reports MERGEABLE; new checks are pending.

Unverified: fresh native iOS runtime evidence. Chrome on this Linux VM cannot exercise UIKit/WKWebView safe-area handling. This merge introduces no UI behavior relative to current main; the original contributor's evidence remains prior evidence.

Note

Written by gpt-6.1-sol on behalf of Maria

Verified in a real dev environment

no changed runtime behavior was verified in a running app on this linux boat vm. this is an unverifiable result, not a runtime pass.

i fetched current github/main (7c6446b81a18afdd3898e1359b401d6f9763fffa) and the exact contributor head (914dacb629aa77d25039fedebb04a571d98ac8d5), read the description, discussion, commit authors and diff, and inspected the mobile entry points. the pr is open and its listed commits are by Claudesaul/Claude Belizaire and maria-rcks, with no listed commits by @juliusmarminge or @t3dotgg.

the remaining diff is one explanatory comment in apps/mobile/src/features/threads/HtmlRenderWebView.tsx. main already has contentInsetAdjustmentBehavior={props.nested ? "never" : "automatic"}. there is therefore no original inset bug to reproduce on current main and no runtime difference to demonstrate between these revisions. the original behavior is reached by expanding an agent-rendered html page from a native mobile thread into the attachment screen, which renders HtmlRenderWebView with nested={false}.

reported github checks currently pass or skip; none are failing or pending. these are ci observations, not fresh runtime verification.

Not verified

ios expanded-page positioning below the translucent header, bottom safe area, short-page pull/bounce behavior, long-page scrolling, and returning to the inline page remain unverified. this vm runs linux and has no xcrun or ios wkwebview runtime. chrome/playwright mobile emulation cannot exercise native uikit safe-area adjustment. adb devices -l also lists no attached android devices.

no dev server, provider turn, dependency installation, screenshots or recordings were run for an unrelated web path. the main/pr startup and before/after steps were not performed because the target runtime is unavailable and current main already contains the behavior. prior contributor simulator captures in the description were not reproduced here and are not claimed as fresh evidence.

no source changes, commits, pushes, labels, merges, rebases or force-pushes were made. native ios verification is still needed before treating the original fix as runtime-verified.