Repository navigation
[Bug]: PiP reflows chat and is constrained to the right-hand lane after V2 #14929
Description
Activity
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.
- addedenhancementRequested improvement or new capability.Requested improvement or new capability.via-triageFiled through npx t3 triageFiled through npx t3 triage
on 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
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
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
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
v0.0.45/6c8fed35dd.v0.0.46-preview.20261002.2598/b37fcea42f.de34391427). The 0.45 preview channel already included the new layout, so the stable 0.45 tag is the baseline here.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.