From 5ceceb262dc1f045c6d42a9cc2329645b1b3ddf9 Mon Sep 17 00:00:00 2001 From: Nicolas Date: Wed, 16 Sep 2026 22:55:51 +0200 Subject: [PATCH] Fix the music bar progress bar not spanning full width on desktop trackProgress is musicBarPanel own first child inside a 3-column grid (track/transport/side), with no grid-column of its own - auto-placement dropped it into column 1 of row 1 like any other item, squeezing it to that columns width and wrapping musicBarPanelSide onto a second row underneath instead of spanning the full bar with everything else in one row below, as its own comment already said it should. Fixed with grid-column: 1 / -1, which pushes every sibling after it into row 2 across the full width with no changes needed to any of them. Co-Authored-By: Claude Sonnet 5 --- README.md | 4 ++++ client/src/musicBar/MusicBar.css | 14 ++++++++++- docs/architecture.md | 41 ++++++++++++++++++++++++++++++++ 3 files changed, 58 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 980ead2..7fe05fa 100644 --- a/README.md +++ b/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) diff --git a/client/src/musicBar/MusicBar.css b/client/src/musicBar/MusicBar.css index ed6d833..c37748f 100644 --- a/client/src/musicBar/MusicBar.css +++ b/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); diff --git a/docs/architecture.md b/docs/architecture.md index 924f636..e3375d8 100644 --- a/docs/architecture.md +++ b/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