Skip to content

[Bug]: PiP reflows chat and is constrained to the right-hand lane after V2 #14929

Description

@PixPMusic

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

  1. Open a thread with enough text to see line wrapping. Keep the main sidebar open and use a 1440×900 window.
  2. 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.
  3. Compare its default position with 0.45. Drag it left and right, then up and down. Resize it from its west edge.
  4. 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 MiniPlayerShell and 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

  1. juliusmarminge commented on Oct 2, 2026

    @juliusmarminge
    Member

    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 (in chatCanvasLayout.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-end inset. 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.ts covers these cases on purpose.

    This geometry arrived with the V2 merge in #2829 (merged). v0.0.45 didn'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 through MiniPlayerShell, 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.

  2. PixPMusic commented on Oct 2, 2026

    @PixPMusic
    ContributorAuthor

    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:

    0.45 PiP default position

    After dragging left; the conversation and input keep their position and width:

    0.45 PiP dragged left

    Movement recording: left, farther left, right, up, down, then resize.

    v045-movement.mp4

    0.46 preview — reserved lane and reflow

    Default position:

    0.46 PiP default position

    After dragging left; PiP stops at the reserved lane and the conversation and input shift and narrow:

    0.46 PiP dragged left with chat reflow

    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
  3. PixPMusic commented on Oct 2, 2026

    @PixPMusic
    ContributorAuthor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementRequested improvement or new capability.via-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions