yonlu/yellowjacket
1
1
Fork 0
Code Issues 55 Pull Requests 6 Actions Packages Projects Releases 12 Wiki Activity

Android: Now Playing's art collapses to a sliver once the transport is thumb-sized #172

New Issue
Closed
opened 2026-08-21 03:37:26 +00:00 by logan · 1 comment
logan commented 2026-08-21 03:37:26 +00:00
Collaborator
Copy Link
Copy Source

Report

On the reference device's 424x439, now-playing-view's album art is a
39px sliver. The screen is legible and nothing overlaps, but the one
thing a Now Playing screen exists to show is the smallest element on it.

Measured after #56 gave the transport thumb-sized controls:

element height
header 48
art 39
title / artist / album ~66
seek bar ~30
transport (controls + secondary row + volume) 172

The art is flex: 1 1 auto, so it absorbs whatever is left over, and at
this height that is almost nothing.

Findings

  • This is a consequence of #56 and not a defect in it. The transport
    was 33x21 buttons in a ~78px block before; it is 44-64px buttons in a
    172px block now, which is what "the playback controls are the most
    important thing in the mobile app and they are tiny" asked for. The
    vertical budget is simply spent.
  • A separate, real overlap bug was fixed on the way and is not this
    issue.     The art is width: min(100%, 60vh); aspect-ratio: 1, so its
    height was derived from its width and bounded by nothing: it drew over
    the header above and the title below. max-height: 100% is in as part
    of #56. That defect pre-dates both issues — screenshotted on main —
    and was found by reading a screenshot, which is the only tier that can
    see it.
  • Two things would give the space back, and both are already filed.
    #64 wants the volume control gone on Android entirely, which is ~30px
    of that 172 including its gap. #51 is the small-screen umbrella and
    explicitly says to verify after this phase, "since each buys
    vertical space".
  • One cheaper option was considered and rejected here: folding shuffle
    and repeat back onto the primary row below some height. It buys ~52px
    — the art goes 39 -> 91, still a sliver — and costs a third
    arrangement of the same five buttons, with a DOM order that differs
    from both existing ones. Not worth it for that.

Direction

Do #64 first and re-measure; it is the one item that is pure gain here.
Then decide whether the art gets a floor (a min-height with the block
above it scrolling) or whether this screen simply reflows below some
height — which is #51's question, and this issue is evidence for it
rather than a competing answer.

**Report** On the reference device's 424x439, `now-playing-view`'s album art is a **39px sliver**. The screen is legible and nothing overlaps, but the one thing a Now Playing screen exists to show is the smallest element on it. Measured after #56 gave the transport thumb-sized controls: | element | height | |---|---| | header | 48 | | **art** | **39** | | title / artist / album | ~66 | | seek bar | ~30 | | transport (controls + secondary row + volume) | **172** | The art is `flex: 1 1 auto`, so it absorbs whatever is left over, and at this height that is almost nothing. **Findings** - This is a *consequence* of #56 and not a defect in it. The transport was 33x21 buttons in a ~78px block before; it is 44-64px buttons in a 172px block now, which is what "the playback controls are the most important thing in the mobile app and they are tiny" asked for. The vertical budget is simply spent. - **A separate, real overlap bug was fixed on the way and is not this issue.** The art is `width: min(100%, 60vh); aspect-ratio: 1`, so its height was derived from its width and bounded by nothing: it drew over the header above and the title below. `max-height: 100%` is in as part of #56. That defect pre-dates both issues — screenshotted on `main` — and was found by reading a screenshot, which is the only tier that can see it. - **Two things would give the space back, and both are already filed.** #64 wants the volume control gone on Android entirely, which is ~30px of that 172 including its gap. #51 is the small-screen umbrella and explicitly says to verify *after* this phase, "since each buys vertical space". - One cheaper option was considered and rejected here: folding shuffle and repeat back onto the primary row below some height. It buys ~52px — the art goes 39 -> 91, still a sliver — and costs a third arrangement of the same five buttons, with a DOM order that differs from both existing ones. Not worth it for that. **Direction** Do #64 first and re-measure; it is the one item that is pure gain here. Then decide whether the art gets a floor (a `min-height` with the block above it scrolling) or whether this screen simply reflows below some height — which is #51's question, and this issue is evidence for it rather than a competing answer.
logan commented 2026-08-21 05:09:55 +00:00
Author
Collaborator
Copy Link
Copy Source

Re-measured after #64, in PR #174. This issue's Direction said to do
that first, and it is worth the ~30px it predicted.

Measured at 424x439 by flipping platformOwnsVolume true in the
!android file and rebuilding — the real binding, the real store, the
real component, everything except the build tag:

element before after
header 48 48
album art 39 68
title / artist / album 63 63
transport 172 143
— seek bar 19 19
— player-controls 116 116
— volume-control 21 0

29px: the 21px control plus the 8px flex gap a hidden box stops
drawing — a gap is only painted between boxes, so :host([hidden])
costs the transport nothing rather than leaving a hole. The art absorbs
all of it, being the only flex: 1 1 auto child, and is 74% larger.

What is left is #51's, which is what the Direction above says. The
art is no longer the smallest element on the screen but it is the
second-smallest, and the two remaining options — a floor with the block
above it scrolling, or this screen reflowing below some height — are
both the umbrella issue's call rather than a competing answer here. The
one cheaper option was already considered and rejected in the Findings
(folding shuffle and repeat onto the primary row: 52px, art at 91px, a
third arrangement of the same five buttons).

So this closes as the evidence it was filed to be, rather than staying
open asking the same question #51 asks. Screenshots before and after
are on #174.

**Re-measured after #64, in PR #174.** This issue's Direction said to do that first, and it is worth the ~30px it predicted. Measured at 424x439 by flipping `platformOwnsVolume` true in the `!android` file and rebuilding — the real binding, the real store, the real component, everything except the build tag: | element | before | after | |---|---|---| | header | 48 | 48 | | **album art** | **39** | **68** | | title / artist / album | 63 | 63 | | **transport** | **172** | **143** | | — seek bar | 19 | 19 | | — player-controls | 116 | 116 | | — volume-control | 21 | **0** | **29px**: the 21px control plus the 8px flex gap a hidden box stops drawing — a gap is only painted between boxes, so `:host([hidden])` costs the transport nothing rather than leaving a hole. The art absorbs all of it, being the only `flex: 1 1 auto` child, and is 74% larger. **What is left is #51's, which is what the Direction above says.** The art is no longer the smallest element on the screen but it is the second-smallest, and the two remaining options — a floor with the block above it scrolling, or this screen reflowing below some height — are both the umbrella issue's call rather than a competing answer here. The one cheaper option was already considered and rejected in the Findings (folding shuffle and repeat onto the primary row: 52px, art at 91px, a third arrangement of the same five buttons). So this closes as the evidence it was filed to be, rather than staying open asking the same question #51 asks. Screenshots before and after are on #174.
logan closed this issue 2026-08-21 05:50:08 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Area/Design
Area/Downloads
Area/Explore
Area/Library-UI
Area/Metadata
Area/Packaging
Area/Player
Area/Queue
Area/Settings
Area/Shell-Nav
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
 Platform/Android
Platform/Desktop
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Medium
3
The priority is medium
Priority
Low
4
The priority is low
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
In Progress
Somebody is actively working on this right now
No labels Area/Player Kind/Bug Platform/Android
Priority
Medium
3
Reviewed
Confirmed
1
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
logan yonlu
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: yonlu/yellowjacket#172