fix(mobile): HTML pages in a thread no longer trap scrolling on Android

[SunkenInTime]

On Android, an agent's HTML page in a thread could trap the feed. Once the page filled the screen, swiping on it moved nothing, so you couldn't scroll up past it. You had to aim for the thin strip of feed outside the page.

The trigger is a page taller than its frame. Frames cap at 2000 px, and agents often write pages longer than that. For those pages HtmlRenderWebView turns on nestedScrollEnabled so the reader can reach the clipped part. On Android, react-native-webview 14.0.1 implements that prop by calling requestDisallowInterceptTouchEvent(true) on every touch, so the feed never gets the gesture back, even when the page is already at its top. iOS and the web hand the gesture to the outer scroller at the edge. Android didn't.

The fix has two parts.

• A pnpm patch to react-native-webview's RNCWebView.onTouchEvent. On a mostly vertical drag, the view lets its parent take over once the document can't scroll any further in that direction. The page scrolls its own hidden part first, then the feed carries on, the way a nested scroll view behaves. A gesture with a second finger, like a pinch, stays with the page until every finger lifts. A document that never scrolls vertically keeps the old behavior on purpose. MCP apps run inside an iframe whose scrolling the outer WebView can't measure, and they rely on keeping every gesture.
• HtmlRenderWebView now reports horizontal and vertical overflow separately, and nested scrolling follows vertical overflow only. A page that's only too wide no longer holds vertical drags, so the feed scrolls over it and sideways panning still reaches the page. iOS still enables page scrolling for overflow in either direction.

I tested on an Android 16 emulator (Pixel 8) with a dev build, using the page that tripped this in a real thread ("Why the 360° replay cuts are slow", about 2,650 px of content in a 2,000 px frame). Same build both times, only the patch and the component toggled. Before, swipes that started on the page left the feed where it was. After, the feed scrolls through the page to the top of the thread. Dragging the other way, the page scrolls its hidden bottom section first and then the feed continues to the end:

I also checked a page that's only too wide (a 1,800 px table in a frame that fits it vertically). A sideways swipe pans the table, and a vertical swipe on it scrolls the feed.

Known limit, seen on the emulator: the native view only knows the document's scroll position, not which element is under the finger. In a page taller than its frame, a scrollable box scrolls down fine. But dragging it back up while the page sits at its own top moves the feed instead. Before this PR that box worked and the whole feed was trapped instead. A related, older problem is unchanged: in a page that fits its frame, a scrollable box never scrolls on Android, because the feed takes every vertical drag. Both deserve a separate fix.

Not covered: I didn't run an MCP app on the device. Its code path is unchanged by construction: its outer document never scrolls vertically, so the patch holds every touch exactly as before. The emulator wouldn't take injected two-finger input, so the pinch handling is checked by reading the code only. There's no automated test, since this is Android touch handling that only a real WebView inside a real scroll view would exercise. The emulator runs above are the evidence. iOS code paths are unchanged.

Made with Claude Opus 5.5 in Claude Code.

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR changes Android’s shared WebView touch-interception behavior, allowing existing nested views to hand vertical gestures to parent feeds at scroll edges. The behavior spans native dependency code and multiple WebView paths, so the runtime interaction warrants human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Path: .coderabbit.config.ts
• Review profile: CHILL
• Plan: Advanced
• Run ID: 7dc65267-7b77-41e9-9b6e-95f946d7d7fa

📥 Commits

Reviewing files that changed from the base of the PR and between 12069ee and f1a6d8e.

⛔ Files ignored due to path filters (1)

• pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml

📒 Files selected for processing (3)

• apps/mobile/src/features/threads/HtmlRenderWebView.tsx
• patches/react-native-webview@14.0.1.patch
• pnpm-workspace.yaml

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

---

📝 Walkthrough

Walkthrough

The WebView now reports horizontal and vertical overflow separately. Android nested scrolling uses vertical overflow, and the patched WebView can yield vertical edge gestures to its scrolling parent.

Changes

Nested WebView scrolling

Layer / File(s)	Summary
Overflow reporting and scroll configuration apps/mobile/src/features/threads/HtmlRenderWebView.tsx	The view reports and stores horizontal and vertical overflow separately. It resets both flags on restart, enables nested scrolling when either axis overflows, and enables Android nested scrolling only for vertical overflow.
Android edge-gesture handling patches/react-native-webview@14.0.1.patch, pnpm-workspace.yaml	The Android patch allows parent interception for vertically dominant single-finger drags when the page reaches its scroll boundary. The workspace applies the patch to react-native-webview@14.0.1.

Priority: ➖ Normal

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Bug fix

Sequence Diagram(s)

sequenceDiagram
  participant HtmlDocument
  participant HtmlRenderWebView
  participant RNCWebView
  participant ScrollParent
  HtmlDocument->>HtmlRenderWebView: Send horizontal and vertical overflow flags
  HtmlRenderWebView->>RNCWebView: Set nested scrolling based on vertical overflow
  ScrollParent->>RNCWebView: Receive vertical drag gesture
  RNCWebView->>ScrollParent: Allow interception at the page scroll boundary

Loading

Suggested reviewers: t3dotgg

Merge Risk: 🔵 Low · up to f1a6d

Scrolling an inner scrollable region inside an HTML page on Android may occasionally move the feed instead of the region when the page is at its top or bottom. The main fix works, and this is a narrow edge case, so the change is mergeable with awareness of the limitation.

Security Architecture Review

Security architecture risk: 🔵 Low · up to f1a6d

The change is bounded to page scrolling, with no new access or privileges identified. Android gesture ordering and delivery of the native fix remain unverified in production.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — In the inspected consumer, page-controlled overflow messages affect local scrolling and feed gesture capture. The native patch is gated by nestedScrollEnabled. No path from the changed telemetry to credentials, attachment mutation, or expanded tenant or service authority was identified.

Trust Boundaries and Controls

• observed — The native message parser validates the message type and boolean fields, but does not authenticate the page as a trusted sender. Its accepted output is confined to presentation state, not authorization or data-integrity decisions. Page-originated control of overflow reporting predates this PR.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly and concisely describes the main Android scrolling fix for HTML pages in threads.
Description check	✅ Passed	The description covers the problem, implementation, verification evidence, limitations, untested cases, and agent disclosure. It does not provide a separate issue or maintainer approval link, but it e…

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

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