Repository navigation
[Bug]: PiP reflows chat and is constrained to the right-hand lane after V2 #14929
Description
Problem
After the V2 orchestrator merge, browser/device picture in picture no longer behaves like a freely movable overlay over the conversation. Dragging it left is constrained to a lane on the right, and moving or resizing it shifts and narrows both the messages and the input field.
I actively want the old floating behavior back for most cases. Keeping a preview visible while reading or typing should not rearrange the conversation underneath it.
Steps to reproduce
- Open a thread with enough text to see line wrapping. Keep the main sidebar open and use a 1440×900 window.
- Open a browser preview or simulator in the right panel and float it over chat. For a simulator: More device actions → Float device over chat.
- Compare its default position with 0.45. Drag it left and right, then up and down. Resize it from its west edge.
- Watch the messages and input field. Repeat at 1920×1080 with the thread-details card open to see how it shares space with PiP.
Expected behavior
Restore floating PiP as the default: movable across the chat canvas, above the messages, with the text and input keeping their position and width. The existing canvas bounds and protection around the input can remain.
An explicit Dock button could make the current reflow behavior useful as an opt-in mode. Undock should return it to the floating overlay. Docking should be a choice; simply opening or dragging PiP should not opt me into reflow.
Actual behavior
| Action | Stable 0.45 | 0.46 preview |
|---|---|---|
| Default position | Upper-right of the chat canvas | Lower-right, beside the input |
| Drag left/right | Can cross the conversation and reach the canvas's left edge; messages/input stay fixed | Stops at a reserved chat lane; messages/input shift left and narrow, then restore when dragged right |
| Drag up/down | Moves over the conversation while avoiding the input | Shares placement constraints with thread details; moving upward can push PiP sideways and shift the chat |
| Enlarge PiP | Leaves messages/input geometry unchanged | Changes chat layout and can compress or hide thread details |
At 1440×900, the same leftward gesture leaves the 0.45 input at x=477, width=742px. In 0.46, PiP stops at x=928, and the input moves from x=453, width=710px at the default PiP position to x=289, width=614px. These are CSS pixels from the page origin. Baseline widths differ between releases; the regression is the position/width changing within the same version as PiP moves.
Versions and verification
- Before:
v0.0.45/6c8fed35dd. - After:
v0.0.46-preview.20261002.2598/b37fcea42f. - Introduced on main with feat(orchestrator): introduce new orchestrator #2829 (
de34391427). The 0.45 preview channel already included the new layout, so the stable 0.45 tag is the baseline here. - Captured on macOS using an iPhone 17 Pro simulator stream inside the web client in T3's internal browser, with identical sample conversations and isolated state. No native mobile app was tested.
- The recordings use synthetic pointer gestures through the actual PiP drag/resize handlers, with native pointer-capture bookkeeping bypassed. They demonstrate layout behavior, not manual hit-target ergonomics.
- Simulator PiP was directly exercised. Browser PiP uses the same
MiniPlayerShelland layout functions; desktop native always-on-top PiP was not tested.
Relevant source
The new chat canvas layout reserves a minimum chat lane while dragging and derives the chat insets from PiP's frame. Thread details participate in the same placement. The 0.45 PiP shell instead measures the canvas/composer and floats without changing chat layout.
Before/after screenshots and movement recordings are attached below.
Activity
juliusmarminge commentedon Oct 2, 2026
Note
Grok responding on behalf of Julius.
Triage
Thanks for the careful measurements, @PixPMusic. They line up exactly with how the new chat-canvas layout works.
What you're seeing is the current design rather than a broken clamp.
resolveChatCanvasLayout(inchatCanvasLayout.ts) keeps a readable chat lane to the left of a dragged preview (canvas padding + a 640px minimum chat width + gap), and it derives the transcript and composer insets from the preview's frame. So a leftward drag stops at that lane, and the messages and input shift and narrow, then return once the preview moves back into the right margin. Your numbers (the player stopping short of the conversation, and the input moving from about x=453 / 710px to about x=289 / 614px) are that lane clamp and the--chat-lane-inset-endinset. A newly opened player is placed beside the composer, and a drag also clears the thread-details card, which is why dragging upward can slide the player sideways.chatCanvasLayout.test.tscovers these cases on purpose.This geometry arrived with the V2 merge in #2829 (merged).
v0.0.45didn't have it; that release's mini player only clamped to the canvas and the composer, so the message and input geometry stayed fixed. Browser and device players both go throughMiniPlayerShell, so they behave the same way.Bringing back the free-floating overlay as the default, with today's reflow behind an explicit Dock control, would change a deliberate default. That's worth proposing in an Ideas discussion so the maintainers can weigh in on direction before anyone builds it. I'm tagging this as an enhancement for now and leaving it open.
PixPMusic commentedon Oct 2, 2026
Before/after evidence from stable 0.45 and 0.46 preview, using the same conversation and a simulator stream inside the browser client.
Stable 0.45 — floating overlay
Default position:
After dragging left; the conversation and input keep their position and width:
Movement recording: left, farther left, right, up, down, then resize.
v045-movement.mp4
0.46 preview — reserved lane and reflow
Default position:
After dragging left; PiP stops at the reserved lane and the conversation and input shift and narrow:
The same movement sequence:
v046-movement.mp4
At 1920×1080, enlarging PiP compresses and then hides the thread-details card:
v046-wide-grow-movement.mp4
PixPMusic commentedon Oct 2, 2026
Moved to Ideas discussion #14935: #14935. The full report and all before/after screenshots and recordings are included there. Closing this issue so the proposal has one place for discussion.