README.md

@@ -382,6 +382,10 @@ Then put it behind your existing reverse proxy like everything else
 - [x] Fixed library tile buttons rendering on top of the sticky header
       while scrolling — an equal z-index tie that a scrolling tile won
       — see docs/architecture.md
+- [x] Fixed the music bar's desktop layout for real — the progress bar
+      was missing a grid-column span, so it (and not just the queue
+      popup above) was still squeezed and wrapping controls onto a
+      second row — see docs/architecture.md
 - [ ] Try a full party end-to-end with two real accounts (still the main gap)
 - [ ] Try casting to a real Chromecast (only the SDK's own bootstrap is
       confirmed here — no real device/session)

client/src/musicBar/MusicBar.css

@@ -26,8 +26,20 @@
    matters most for drag on a touch screen, same trick
    views/player/Player.css's own .progressBar::before uses.
    `position: relative` is what gives that absolutely-positioned
-   ::before something to size itself against. */
+   ::before something to size itself against.
+   `grid-column: 1 / -1` is the fix, not decoration: #trackProgress is
+   .musicBarPanel's first child, and without an explicit span a 3-column
+   grid places it in column 1 alone - squeezing it down to the width of
+   .musicBarPanelTrack's own column and wrapping .musicBarPanelSide onto
+   a second row underneath it, instead of the intended full-width strip
+   with everything else in one row below. Reported directly - never
+   looked obviously wrong at a glance since .musicBarPanelTrack's own
+   content (a small image + short text) left column 1 wide enough to
+   mostly hide the squeeze. Spanning this row is what pushes every
+   sibling after it into row 2, across all 3 columns, with no change
+   needed to them. */
 .musicBarProgressTrack {
+  grid-column: 1 / -1;
   position: relative;
   height: 3px;
   background: rgba(255, 255, 255, .12);

docs/architecture.md

@@ -4196,6 +4196,47 @@ the stack exactly as reported; restored to `3`, the header (and the
 search input inside it) topped it instead, `.tileOverlay` three layers
 down, unreachable.
 
+## The music bar's compact layout: the progress bar was never actually full-width
+
+Reported directly, again, after the queue-popup fix above - the desktop
+bar still didn't look right: the progress bar needed to span the full
+width, with everything else in one row underneath.
+
+`.musicBarProgressTrack`'s own comment already described it as "a thin
+strip along the bar's own top edge" - the intent was always a full-width
+strip above a row of controls, mirroring Spotify/YouTube Music's own
+compact players. But `#trackProgress` (that element) is `.musicBarPanel`'s
+*first* child inside a 3-column grid (`.musicBarPanelTrack`/
+`.musicBarPanelTransport`/`.musicBarPanelSide`), with no `grid-column`
+of its own - so grid auto-placement dropped it into column 1 of row 1
+like any other item, squeezing it to that column's own width and
+wrapping `.musicBarPanelSide` onto a second row underneath it instead.
+Easy to miss at a glance: with no track loaded, `.musicBarPanelTrack`'s
+own content (a small image + short placeholder text) still left column
+1 wide enough that the squeeze didn't look obviously broken - see the
+queue-popup section above for the *other* half of "cassé en desktop",
+found and fixed first without this one.
+
+Fixed with one line: `.musicBarProgressTrack { grid-column: 1 / -1; }`.
+Spanning all 3 columns in row 1 is what pushes every sibling after it
+(auto-placed, no changes needed to any of them) into row 2, across the
+full width - track/transport/side exactly where the 3-column rule
+already intended them, just no longer sharing row 1 with the progress
+bar.
+
+Verified: full `typecheck`/`build` (client only). Checked directly - a
+synthetic page with real compiled CSS, `initMusicBar` called against a
+reproduction of the real Shell markup, a fake track's name/artist/
+position set so `.musicBarPanelTrack` has realistic content width. Read
+back with `getBoundingClientRect()`: the progress bar's own width
+matched `.musicBarPanel`'s full content width exactly (not the viewport,
+which include its own outer padding); its bottom edge sat at or above
+every other row's top edge; and the other three elements' vertical
+ranges genuinely overlapped each other (not just similar `top` values,
+which `align-items: center` legitimately varies by each one's own
+content height) - confirming one shared row below, in the original
+track/transport/side left-to-right order.
+
 ## Known limitations
 
 - Playback always goes through `hls.js` against whatever Emby's