Repository navigation
[Bug]: Mini player page stays behind when the sidebar toggles with the player on the left #13776
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/web
Steps to reproduce
- In the desktop app, open a browser preview for a thread and send it to the floating mini player.
- Drag the mini player to the left edge of the chat column, next to the sidebar.
- Collapse or expand the left sidebar.
Expected behavior
The page inside the mini player moves with the mini player's frame.
Actual behavior
The mini player's frame moves with the chat column, but the page rendered inside it stays where it was. The page ends up offset from its frame and can sit over the chat. When the mini player is on the right edge, the page follows correctly.
Impact
Minor bug or occasional failure
Version or commit
0.0.43-nightly.20260926.2282
Environment
macOS 27, T3 Code (Nightly) desktop app
Logs or stack traces
n/aScreenshots, recordings, or supporting files
(screenshot attached below)
Workaround
Drag the mini player a little, or resize the window. Either action makes the page re-measure its position.
Likely cause
BrowserSurfaceSlot re-measures its screen rect only when the slot itself resizes, on window resize or scroll, or when layoutVersion changes. For the mini player, layoutVersion is ${frame.x}:${frame.y}, and the frame position is relative to the chat column. When the sidebar gap animates its width, the chat column shifts and resizes. A right-anchored frame gets a new frame.x, which triggers a re-measure. A left-anchored frame keeps the same frame.x and frame.y, so nothing triggers a re-measure and the fixed-position webview stays at the stale rect. The inline preview panel already has an equivalent workaround that observes the [data-preview-panel-mode="inline"] shell.
Activity
juliusmarminge commentedon Sep 26, 2026
Confirmed. Desktop-only, and still present on
main(nightly0.0.43-nightly.20260926.2282). Not a duplicate.The floating frame is ordinary CSS inside the chat column, so it moves with
[data-slot="sidebar-gap"]. The page is the Electron<webview>inHostedBrowserWebview, which isposition: fixedat the last rect fromBrowserSurfaceSlot. That slot remeasures only when its own box resizes, the window resizes or scrolls,layoutVersionchanges, or an ancestor[data-preview-panel-mode="inline"]resizes. The mini player is not inside that inline shell.layoutVersionis${frame.x}:${frame.y}inThreadPreviewMiniPlayer, and those values are relative to the chat column. A player on the left keeps the same relative origin when the column shifts, so nothing remeasures and the webview stays on the stale screen rect. The untouched top-right player follows because itsxis recomputed from the column width (positionis still null). Any stored position whose relativex/ydo not change misses the same way, including a player dragged to the right edge when the column grows on sidebar collapse. Clamping only pulls a storedxinward.Dragging the player or resizing the window remeasures, which matches the workaround. Turning panel animations off does not: the column still jumps and
layoutVersionstill does not change. Device mini players are in-DOM and are not affected.#12329 only taught the slot to observe the inline preview shell. The sidebar gap needs the same kind of observation: remeasure when the slot’s viewport origin moves, not only when its relative frame origin or its own size changes.
fix(web): floating preview page follows its frame when the sidebar to…
fix(web): floating preview page follows its frame when the sidebar to…
fix(web): floating preview page follows its frame when the sidebar to…