README.md

@@ -382,10 +382,6 @@ 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,20 +26,8 @@
    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,47 +4196,6 @@ 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