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 `