fix(mobile): browser picture in picture opens from the header button

[juliusmarminge]

Problem

Tapping picture in picture in the mobile browser view always shows "Picture in picture is unavailable. The request is not triggered by a user activation."

The native header button calls injectJavaScript, and the viewer then ran await video.play() before requestPictureInPicture(). WebKit gives an injected script a forced user activation. For apps built on the iOS 17 SDK or later (SDKAlignedBehavior::EvaluateJavaScriptWithoutTransientActivation), it takes that activation back once the script's gesture token goes away. By the time play() settled, the activation was gone, so the request was rejected every time.

Fix

preview-stream.browser.ts now asks for picture in picture synchronously, inside the injected call:

• The interactive viewer sets up its video at startup: paused, with no autoplay, playing a canvas.captureStream(0) stream. With a frame rate of 0, nothing is captured unless we request it.
• After each paint, a frame is requested only while the video has none or is floating. The inline view therefore does no capture or encode work, and a static page still gets its frame.
• The toggle calls requestPictureInPicture() first, then play(), and treats a failure of either as one error. If no frame has arrived yet, it says so instead of failing.
• The canvas now uses the viewer background, so the paused video under the letterbox never shows through.

Verification

• I wrote a small Swift app that runs WKWebView on macOS. The media-stream player and the activation logic are shared with iOS.
  • The old flow (await play(), then request) reproduces the exact error, with navigator.userActivation.isActive === false after the await.
  • The new flow enters picture in picture, exits, and re-enters. The floating video follows canvas resizes, and the video stays paused inline.
  • A single paint right after setup reaches HAVE_ENOUGH_DATA once it lands one task later. A same-task paint does not, which is why the frame request repeats after each paint while the video has no frame.
• tsc --noEmit (mobile), vp lint, vp fmt --check all pass.
• Not yet checked on an iOS device or simulator.

Opus 5.5 in Claude Code, running in T3 Code.

🤖 Generated with Claude Code

---

[macroscopeapp]

Approvability

Verdict: Approved at 9aec56b

Macroscope's review found this PR approvable — This is a focused one-file fix for the existing mobile browser picture-in-picture flow. It changes only PiP media initialization, activation ordering, frame delivery, and cleanup, without affecting unrelated browser rendering or introducing schema, infrastructure, or sensitive-data changes.

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

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	5.0 KiB	5.0 KiB	0 B (0.0%)	6.8 KiB	✅
Codex	Thread snapshot wire	3.8 KiB	3.8 KiB	0 B (0.0%)	4.9 KiB	✅
Codex	Live turn WebSocket wire	1.2 KiB	1.2 KiB	0 B (0.0%)	2.0 KiB	✅
Codex	Live turn WebSocket decoded	20.9 KiB	20.9 KiB	0 B (0.0%)	29.3 KiB	✅
Codex	Live turn messages	2	2	0 (0.0%)	8	✅
Claude	Total thread wire	5.0 KiB	5.0 KiB	+24 B (+0.5%)	6.8 KiB	✅
Claude	Thread snapshot wire	3.8 KiB	3.8 KiB	0 B (0.0%)	4.9 KiB	✅
Claude	Live turn WebSocket wire	1.2 KiB	1.2 KiB	+24 B (+2.0%)	2.0 KiB	✅
Claude	Live turn WebSocket decoded	21.2 KiB	21.2 KiB	+41 B (+0.2%)	29.3 KiB	✅
Claude	Live turn messages	1	2	+1 (+100.0%)	8	✅

Baseline: 4107930 · PR result: 9aec56b · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 108.5 KiB
• Claude decoded thread snapshot: 108.8 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[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: Team
• Run ID: 443f92ad-b48d-48ae-a09a-210d40e3eba3

---

📥 Commits

Reviewing files that changed from the base of the PR and between 4107930 and 9aec56b.

---

📒 Files selected for processing (1)

• apps/mobile/src/features/browser/preview-stream.browser.ts

---

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 browser viewer now prepares picture-in-picture capture during setup, requests frames after paints when needed, and starts or exits presentation without awaiting. The toggle API returns void, and stopping the viewer stops its retained capture track.

Changes

Picture-in-Picture Viewer

Layer / File(s)	Summary
Prepare and refresh capture frames apps/mobile/src/features/browser/preview-stream.browser.ts	Setup creates a zero-rate canvas capture stream and muted inline video. The viewer requests capture frames after paints when the video has no frame or picture-in-picture is active.
Toggle presentation and stop capture apps/mobile/src/features/browser/preview-stream.browser.ts	The toggle API returns void. The viewer checks frame readiness, starts or exits presentation without awaiting, and reports asynchronous failures. Stopping ends the retained capture track.

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Suggested reviewers: maria-rcks

---

Merge Risk: ⚪ Minimal · up to 9aec5

No demonstrated issue prevents merging. Picture-in-picture behavior on iOS remains untested and should be checked during normal validation.

Pre-merge checks | 3 | 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check		The description explains the problem, fix, and verification results in sufficient detail. However, it omits the required Scope and approval section, does not explain an approval exemption, and provide…	Add a Scope and approval section with the triaged issue or maintainer approval, or explain why this focused bug fix qualifies for an exemption. Add before/after UI evidence and a recording if interaction timing requires it.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check		The title clearly and concisely describes the main fix: enabling picture-in-picture from the mobile browser header button.
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

---

Full details: Description check

Explanation

The description explains the problem, fix, and verification results in sufficient detail. However, it omits the required Scope and approval section, does not explain an approval exemption, and provides no UI screenshots or recording.

---

• Fix all pre-merge checks with AI

✨ Finishing Touches

📝 Generate docstrings

• Commit to this branch
• Create a new PR

---

🧪 Generate unit tests (beta)

• Commit to this branch
• 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.}