From 83592f1ee9a55ca5bb4a9e12f495b2a64f3c9a6c Mon Sep 17 00:00:00 2001 From: Nicolas Date: Fri, 18 Sep 2026 11:43:36 +0200 Subject: [PATCH] Fix the music bar mobile now-playing screen not fitting landscape The album art was sized off min(220px, 60vw) - the viewport dimension a phone in landscape has plenty of - and stayed pinned near that cap regardless of how little vertical room was actually left once everything stacked vertically (art, text, transport, side), running well past a typical landscape height and needing to scroll to reach the controls. Added a dedicated media query for max-width 720px and orientation landscape rather than chasing every fixed value in the portrait rules: the art now sits beside the title/artist instead of above them (flex-direction: row), freeing most of the vertical space the portrait layout spends stacking them, and its size is capped by vh instead of vw - the dimension landscape actually constrains. A few margins shrink alongside it in the same block for the same reason. Deliberately left the transport buttons fixed-size - a touch target answers to a finger, not the screen. Co-Authored-By: Claude Sonnet 5 --- README.md | 4 +++ client/src/musicBar/MusicBar.css | 35 +++++++++++++++++++++++++ docs/architecture.md | 45 ++++++++++++++++++++++++++++++++ 3 files changed, 84 insertions(+) diff --git a/README.md b/README.md index 2d71786..6e8bd76 100644 --- a/README.md +++ b/README.md @@ -403,6 +403,10 @@ Then put it behind your existing reverse proxy like everything else falling back to its album's artwork — see docs/architecture.md (probably not the whole "images are hard to find" story — flagged there) +- [x] Fixed the music bar's mobile now-playing screen not fitting a + phone rotated to landscape — the art now sits beside the title + instead of above it, sized off the viewport height instead of a + fixed width-based cap — 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 c37748f..e224d95 100644 --- a/client/src/musicBar/MusicBar.css +++ b/client/src/musicBar/MusicBar.css @@ -388,6 +388,41 @@ } } +/* Rotated: the block above stacks the art on top of everything else and + sizes it off the viewport's WIDTH (60vw) - reported directly as + overflowing/needing to scroll once width and height swap roles in + landscape, where width is the one dimension this screen never lacks. + Same fixed-overlay itself, just laid out differently - the art moves + beside the title/artist instead of above them (freeing most of the + vertical stack this screen otherwise spends on it), and every size + below is capped by `vh`, the scarce dimension here, not `vw`. Button + sizes are deliberately left alone (56px .musicBarPlayBig, the same + above) - a touch target sizes to a finger, not the screen, in any + orientation. */ +@media (max-width: 720px) and (orientation: landscape) { + .musicBarPanel { + padding-top: 10px; + padding-bottom: calc(10px + env(safe-area-inset-bottom, 0px)); + } + + .panelCloseBtn { margin-bottom: 6px; } + + .musicBarPanelTrack { + flex-direction: row; + text-align: left; + margin-bottom: 8px; + } + + .musicBarPanelTrack .musicBarImage { + width: min(120px, 20vh); + height: min(120px, 20vh); + } + + .musicBarInfo { align-items: flex-start; } + + .musicBarPanelTransport { margin-bottom: 8px; } +} + /* One queue entry - a plain flex row (image, then a shrinking/truncating info column, then the duration), NOT views/album's shared .trackRow grid (styles/trackList.css) - that one's 4 fixed columns assume diff --git a/docs/architecture.md b/docs/architecture.md index 85fba14..cbc4996 100644 --- a/docs/architecture.md +++ b/docs/architecture.md @@ -4517,6 +4517,51 @@ request includes `Fields=AlbumId` (a mocked `EmbyClient.fetch` capturing the real path/query it was called with, not just asserting on the already-separately-tested `imageUrlFor` logic downstream of it). +## The music bar's mobile now-playing screen didn't fit landscape + +Reported directly, along with a fair general complaint: the mobile +now-playing overlay used mostly fixed sizes, and the one that mattered +most - the album art - was sized off `vw` (`min(220px, 60vw)`), the +viewport dimension a phone in landscape has *plenty* of. Stacked +vertically (art, then text, then the transport row, then the side row) +with that same art staying pinned near its 220px cap regardless of how +little vertical room was actually left, the screen ran well past a +typical landscape phone's height and needed to scroll to reach the +transport controls - not adapted to the rotation at all. + +Fixed with a dedicated `@media (max-width: 720px) and +(orientation: landscape)` block, not by chasing every fixed value in +the portrait rules: the art moves beside the title/artist instead of +above them (`.musicBarPanelTrack` becomes `flex-direction: row`), +freeing most of the vertical space the portrait layout spends stacking +them - and every size that actually needs to respond to the rotation is +now capped by `vh` (`min(120px, 20vh)`), the dimension landscape +actually constrains, instead of `vw`. A few fixed margins shrink +alongside it in this same block, same reasoning: adapting to less +vertical room, not arbitrary tightening. + +Deliberately NOT changed: `.musicBarPlayBig`'s 56px transport button +and the other icon buttons. A touch target's size answers to a +finger, not the screen - shrinking it in landscape to "adapt" would +trade a real usability problem (nothing to tap accurately) for a +cosmetic one, the opposite of the actual ask. + +Verified: full `typecheck`/`build` (client only). Checked directly, not +just reasoned about - real compiled CSS with the real markup loaded +into `