The phone transport: three controls, sized for a thumb (#59, #56) #173

Merged

logan merged 5 commits from 59-slim-the-mini-player into main 2026-08-21 04:14:40 +00:00

Conversation 2 Commits 5 Files Changed 11

+1127 -84

logan commented 2026-08-21 03:43:28 +00:00

Collaborator

Copy Link

Copy Source

Closes #59, #56.

Two issues, one PR, argued on #73 before starting rather than batched
silently: they are the same component and the same row of pixels — #59
removes controls from the phone's transport, #56 enlarges what is left —
and both issues already asked to be sequenced together in their own text.
Done apart, the bar gets laid out twice and the first PR ships a state
neither issue wants.

Measured at 424x439, the reference device's real viewport

control	before	after
bar: shuffle / prev / play / next / repeat	33x21 each	prev/next 44, play 56; shuffle+repeat moved
bar: favourite	18x14 — smallest control in the app	44x44
bar: queue button	33x29	gone (#59)
Now Playing: all five	33x21 each	44, play 64
desktop bar: all five	33x21	33x21

The design

The context is a property, not a media query, and that is the one
decision here. Everywhere else a component states what it drops at phone
width itself, because a media query inside a shadow root is answered by
the viewport. Here the two hosts want different answers at the same
viewport: the bar wants three controls, now-playing-view wants five,
larger still. So the host says which context and the viewport says which
size band. Sizes are --yj-control-* per context; play/pause alone goes
above the 44px floor, because a row of identical squares says every
action is equally likely and that is not true of play.

The phone draws three buttons rather than hiding two, from
matchMedia (job-band's pattern). A display: none control is still
in the shadow root and still something a positional query finds, so
"the phone has three controls" would have been true of the pixels and
false of the element.

Removing a control is only allowed because it is still reachable —
plan 018's matrix promise — so the spec walks the route rather than
counting buttons. #55 merging is what makes the queue half safe: it is a
screen with a back stack now.

Four things that failed silently

Each cost a cycle, none was visible to any assertion in the repo, and
all four are in .planning/NOTES.md.

1. The route to Now Playing did not exist in the state that matters.
   now-playing renders two branches and the no-track one had no
   .expand button, so with nothing loaded there was no way to the
   full-screen view — and once the queue button left the bar, no way to
   the queue at all. The queue is persisted across restarts, so "tracks
   queued, nothing playing" is a state the app launches into. Fixed
   here, and pinned by a spec that clears the queue itself.
2. A <button> does not inherit its font from its parent — the UA
   stylesheet gives it one. So a generic font-size: inherit is not the
   no-op it reads as: it took every desktop button from 33x21 to 36x24.
   Found only by stashing the file and measuring the baseline. The
   desktop sizes are now asserted as the literal '33x21', because a
   range swallows three pixels.
3. A rule at the bottom of index.css still loses to a nested rule
   above it. The phone block is last because a media query adds no
   specificity — but #queue-button is written nested inside
   .bottom-bar, so it builds one class more specific and a bare
   #queue-button { display: none } did nothing. The button simply
   stayed.
4. The album art overflowed its own box, drawing over the header and
   the title: aspect-ratio: 1 with a definite width derives a height
   that nothing bounds, and 60vh bounds the viewport, not the room
   left over. max-height: 100%. Pre-existing — screenshotted on main
   — and found by reading a screenshot, the only tier that can see
   it: nothing fails, the shell does not overflow, every control is
   still hittable.

Commits

commit	issue	what
218e4f5 feat(player): give the transport a context, and thumb-sized controls	#56	the context property, the sizes, the art's max-height
32d4dc2 feat(player): slim the phone's mini player to three controls	#59	the three that leave the bar, the favourite's size, the no-track route
f65822c test(player): pin the phone transport, and the desktop bar not moving	#59, #56	phone-transport.spec.ts, openTheQueue in the fixtures
c7e5a4f docs(player): record the phone transport, and four silent failures	—	CLAUDE.md, .planning/NOTES.md

Verification actually run

gate	result
make e2e	220 passed (whole suite)
make ui-test	974 passed (968 before; +6 from transport-context.test.ts)
tsc --noEmit in frontend/ and e2e/	clean, both
make css-check	142 files, no broken literals
make lint	0 issues, three tag sets — formality, no Go changed
make test	green, three tag sets — formality
make bindings-check / make skill-check	current / 47 targets — formalities

--project=webkit is not configured locally; check CI's WebKit step
actually ran (if: !cancelled() has silently skipped it before).

The suite is what caught this change, twice. An intermediate build
failed ten tests in four files — queue-as-a-screen,
queue-overlay — none of which is about the transport: every one opened
the queue by clicking #queue-button, and so was asserting which
route exists as well as what the queue does. That is the third change in
a row where the spec I wrote was green and something else was not.

The specs bite

Reverted frontend/, rebuilt, re-ran: 5 of 10 fail, including the
reachability one. The desktop guards pass there and are meant to — they
exist to catch a change to a bar neither issue is about, which is
exactly what they did.

What is deliberately not done

• #172, filed: with the transport at 172px of a 439px screen the art
  is a 39px sliver. That is a consequence of #56 rather than a fault
  in it. #64 (~30px) and #51 are where the space comes back. Folding
  shuffle and repeat onto the primary row was considered and rejected —
  it buys 52px, leaves the art at 91, and costs a third arrangement of
  the same five buttons.
• #64 is not touched, and a comment on it records that its first
  Finding is misleading: the bar's copy is gone by width, but
  now-playing-view renders a volume slider that is visible on a phone,
  deliberately and in writing. Platform-versus-width is the crux and the
  frontend has no isAndroid signal.

Screenshots at 424x439 and 1280x800 in a comment below.

Closes #59, #56. Two issues, one PR, argued on #73 before starting rather than batched silently: they are the same component and the same row of pixels — #59 removes controls from the phone's transport, #56 enlarges what is left — and both issues already asked to be sequenced together in their own text. Done apart, the bar gets laid out twice and the first PR ships a state neither issue wants. ## Measured at 424x439, the reference device's real viewport | control | before | after | |---|---|---| | bar: shuffle / prev / play / next / repeat | **33x21** each | prev/next 44, play 56; shuffle+repeat moved | | bar: favourite | **18x14** — smallest control in the app | 44x44 | | bar: queue button | 33x29 | gone (#59) | | Now Playing: all five | **33x21** each | 44, play 64 | | **desktop bar: all five** | 33x21 | **33x21** | ## The design **The context is a property, not a media query**, and that is the one decision here. Everywhere else a component states what it drops at phone width itself, because a media query inside a shadow root is answered by the viewport. Here the two hosts want different answers at the *same* viewport: the bar wants three controls, `now-playing-view` wants five, larger still. So the host says which context and the viewport says which size band. Sizes are `--yj-control-*` per context; play/pause alone goes above the 44px floor, because a row of identical squares says every action is equally likely and that is not true of play. **The phone draws three buttons rather than hiding two**, from `matchMedia` (`job-band`'s pattern). A `display: none` control is still in the shadow root and still something a positional query finds, so "the phone has three controls" would have been true of the pixels and false of the element. **Removing a control is only allowed because it is still reachable** — plan 018's matrix promise — so the spec walks the route rather than counting buttons. #55 merging is what makes the queue half safe: it is a screen with a back stack now. ## Four things that failed silently Each cost a cycle, none was visible to any assertion in the repo, and all four are in `.planning/NOTES.md`. 1. **The route to Now Playing did not exist in the state that matters.** `now-playing` renders two branches and the no-track one had **no `.expand` button**, so with nothing loaded there was no way to the full-screen view — and once the queue button left the bar, no way to the queue at all. The queue is persisted across restarts, so "tracks queued, nothing playing" is a state the app *launches into*. Fixed here, and pinned by a spec that clears the queue itself. 2. **A `<button>` does not inherit its font from its parent** — the UA stylesheet gives it one. So a generic `font-size: inherit` is not the no-op it reads as: it took every desktop button from 33x21 to 36x24. Found only by stashing the file and measuring the baseline. The desktop sizes are now asserted as the literal `'33x21'`, because a range swallows three pixels. 3. **A rule at the bottom of `index.css` still loses to a nested rule above it.** The phone block is last because a media query adds no specificity — but `#queue-button` is written nested inside `.bottom-bar`, so it builds one class more specific and a bare `#queue-button { display: none }` did nothing. The button simply stayed. 4. **The album art overflowed its own box**, drawing over the header and the title: `aspect-ratio: 1` with a definite width derives a height that nothing bounds, and `60vh` bounds the *viewport*, not the room left over. `max-height: 100%`. Pre-existing — screenshotted on `main` — and **found by reading a screenshot**, the only tier that can see it: nothing fails, the shell does not overflow, every control is still hittable. ## Commits | commit | issue | what | |---|---|---| | `218e4f5` `feat(player): give the transport a context, and thumb-sized controls` | #56 | the context property, the sizes, the art's `max-height` | | `32d4dc2` `feat(player): slim the phone's mini player to three controls` | #59 | the three that leave the bar, the favourite's size, the no-track route | | `f65822c` `test(player): pin the phone transport, and the desktop bar not moving` | #59, #56 | `phone-transport.spec.ts`, `openTheQueue` in the fixtures | | `c7e5a4f` `docs(player): record the phone transport, and four silent failures` | — | `CLAUDE.md`, `.planning/NOTES.md` | ## Verification actually run | gate | result | |---|---| | `make e2e` | **220 passed** (whole suite) | | `make ui-test` | **974 passed** (968 before; +6 from `transport-context.test.ts`) | | `tsc --noEmit` in `frontend/` and `e2e/` | clean, both | | `make css-check` | 142 files, no broken literals | | `make lint` | 0 issues, three tag sets — **formality**, no Go changed | | `make test` | green, three tag sets — **formality** | | `make bindings-check` / `make skill-check` | current / 47 targets — **formalities** | `--project=webkit` is not configured locally; check CI's WebKit step actually ran (`if: !cancelled()` has silently skipped it before). **The suite is what caught this change, twice.** An intermediate build failed **ten tests in four files** — `queue-as-a-screen`, `queue-overlay` — none of which is about the transport: every one opened the queue by clicking `#queue-button`, and so was asserting *which* route exists as well as what the queue does. That is the third change in a row where the spec I wrote was green and something else was not. ### The specs bite Reverted `frontend/`, rebuilt, re-ran: **5 of 10 fail**, including the reachability one. The desktop guards pass there and are meant to — they exist to catch a change to a bar neither issue is about, which is exactly what they did. ## What is deliberately not done - **#172, filed**: with the transport at 172px of a 439px screen the art is a **39px sliver**. That is a consequence of #56 rather than a fault in it. #64 (~30px) and #51 are where the space comes back. Folding shuffle and repeat onto the primary row was considered and rejected — it buys 52px, leaves the art at 91, and costs a third arrangement of the same five buttons. - **#64 is not touched**, and a comment on it records that its first Finding is misleading: the bar's copy is gone *by width*, but `now-playing-view` renders a volume slider that is visible on a phone, deliberately and in writing. Platform-versus-width is the crux and the frontend has no `isAndroid` signal. Screenshots at 424x439 and 1280x800 in a comment below.

bar-424.png

52 KiB

npv-424.png

23 KiB

npv-424-BEFORE.png

20 KiB

bar-1280.png

245 KiB

logan added 4 commits 2026-08-21 03:43:28 +00:00

feat(player): give the transport a context, and thumb-sized controls ... 218e4f5e99

Measured at the reference device's 424x439, every button here was
33x21px -- in the bottom bar and on the full-screen view alike. #56
reports them as "the most important thing in the mobile app and they
are tiny", and that is the number behind it.

The context is a **property, not a media query**, and that is the whole
design. Everywhere else in this app a component states what it drops at
phone width itself, because a media query inside a shadow root is
answered by the viewport and that is the honest signal. Here the two
hosts want different answers at the *same* viewport: on a phone the bar
wants three controls sized for a thumb and now-playing-view wants five,
larger still. So the host says which context and the viewport says
which size band, and neither alone can express it.

Play/pause alone goes above the 44px floor. A row of five identical
squares says every action is equally likely, which is not true of play
-- "large play/pause, adequate prev/next" is the Direction, and a spec
caught that the first version had sized all three the same.

Two things that fail silently:

The desktop bar must not move, and a `<button>` does not inherit its
font from its parent -- the UA stylesheet gives it one. So a generic
`font-size: inherit` is not the no-op it reads as: it took every
desktop control from 33x21 to 36x24. The box rules take a zero fallback
and the font-size rules are scoped to the two contexts that set one.

And the art on now-playing-view overflowed its own box, drawing over
the header above and the title below, because `aspect-ratio: 1` with a
definite width derives a height that nothing bounds -- 60vh bounds the
viewport, not the room left over. `max-height: 100%`. Pre-existing;
found by reading a screenshot, which is the only tier that can see it.

What is left is #172: with the transport at 172px of a 439px screen the
art is a 39px sliver.

Closes #56

feat(player): slim the phone's mini player to three controls ... 32d4dc2c82

Shuffle, repeat and the queue button leave the phone's bottom bar.
They are not gone: all three are on the full-screen Now Playing view,
one tap away through the mini player's art, which is the "reachable
only from Now Playing" this issue asks for. #55 is what makes the queue
half safe -- it is a screen with an entry in the back stack now, rather
than a panel with no way out but the button being removed here.

Removing a control is only allowed because it is still reachable, which
is plan 018's matrix promise, so that is what the spec walks rather
than counting buttons. It found that the route did not exist in the
state that matters: `now-playing` renders two branches and the no-track
one had no `.expand` button on its placeholder, so with nothing loaded
there was no way to the full-screen view at all -- and once the queue
button left the bar, no way to the queue. The queue is persisted across
restarts, so "tracks queued, nothing playing" is a state the app
launches into, not a corner.

The favourite stays on the bar and was 18x14px, the smallest control in
the app, against the 48x48 art beside it.

One CSS trap, because it failed silently. The phone block is last in
index.css on purpose -- a media query adds no specificity -- but the
rule it overrides here is written *nested* inside `.bottom-bar`, so it
builds to a descendant selector one class more specific and a bare
`#queue-button` lost to it. Being last is not enough when the thing
above is more specific.

Closes #59

test(player): pin the phone transport, and the desktop bar not moving ... f65822c4b2

Ten tests, five of which fail on the build before this. The desktop
guard is meant to pass there -- that is its job, and it is the one that
caught a three-pixel regression nothing else could see.

`openTheQueue` moves to the fixtures, because hiding one button failed
ten tests in four files about the back stack and about layout: every
one of them opened the queue by clicking `#queue-button`, and so was
quietly asserting *which* route exists as well as what the queue does.
The route differs by width now and that is the feature.

Two smaller things. The play button is named for its action, so an
exact 'Play' waits out a fixture track -- 11.1s per test, passing by
luck, and it would have failed outright against LONG_TRACK. And the
"nothing playing" case clears the queue itself rather than trusting the
app not to have played anything: `make e2e` runs one long-lived app
across every spec (#168), which is how a deterministic bug first showed
up as a flake.

docs(player): record the phone transport, and four silent failures ... c7e5a4f086

The model in CLAUDE.md beside the volume rule it qualifies; the
measurements and the four things that cost a cycle each in NOTES.md,
dated. Three of the four are invisible to every assertion in the repo:
a button not inheriting its font, a nested rule out-specifying a later
one, and art whose height is bounded by nothing.

logan commented 2026-08-21 03:43:44 +00:00

Author

Collaborator

Copy Link

Copy Source

Screenshots

424x439 — the mini player after #59/#56. Three controls, prev/next
44px and play 56px, the favourite at 44px beside the art, no queue
button. This is what the report asked for: the transport is the thing
you can hit.

424x439 — Now Playing, before. On main. The art's height is
derived from its width and bounded by nothing, so it draws over the
header and over the title: "Looking up lyrics" is a job band, but the
disc overlapping NOW PLAYING and the text sitting behind it is the
bug. Nothing fails, nothing overflows the shell, and every control is
still hittable — which is why no tier here could see it.

424x439 — Now Playing, after. Nothing overlaps. Five controls, play
at 64px, shuffle and repeat on their own row. And the art is a 39px
sliver, which is #172 and is stated rather than hidden: the transport
is 172px of a 439px screen, and #64 plus #51 are where that comes back.

1280x800 — the desktop bar, unchanged. Five controls at 33x21, the
queue button present, the favourite at 18x14. Both issues are
Platform/Android; this is asserted with a literal rather than left to
inspection.

## Screenshots **424x439 — the mini player after #59/#56.** Three controls, prev/next 44px and play 56px, the favourite at 44px beside the art, no queue button. This is what the report asked for: the transport is the thing you can hit.  **424x439 — Now Playing, before.** On `main`. The art's height is derived from its width and bounded by nothing, so it draws over the header and over the title: "Looking up lyrics" is a job band, but the disc overlapping `NOW PLAYING` and the text sitting behind it is the bug. Nothing fails, nothing overflows the shell, and every control is still hittable — which is why no tier here could see it.  **424x439 — Now Playing, after.** Nothing overlaps. Five controls, play at 64px, shuffle and repeat on their own row. **And the art is a 39px sliver**, which is #172 and is stated rather than hidden: the transport is 172px of a 439px screen, and #64 plus #51 are where that comes back.  **1280x800 — the desktop bar, unchanged.** Five controls at 33x21, the queue button present, the favourite at 18x14. Both issues are `Platform/Android`; this is asserted with a literal rather than left to inspection. 

logan added 1 commit 2026-08-21 04:02:33 +00:00

test(player): assert the desktop bar's size by mechanism, not by pixels ... e3b64f9255

WebKit draws the same button 36x24 where Chromium draws 33x21, so the
literal this pinned failed in CI on a build where nothing was wrong. A
button's box comes from the UA stylesheet when the author sets nothing,
and what each UA sets is its own business.

What must not happen is that *we* set something. So: `min-width` and
`min-height` compute to 0px, the font-size still equals that of a bare
button probed in the same page, and all five boxes are identical --
which is what says the desktop is neither sized context. Checked by
re-introducing the `font-size: inherit` regression, which it catches in
Chromium; the literal form could only be checked by hand.

logan commented 2026-08-21 04:02:43 +00:00

Author

Collaborator

Copy Link

Copy Source

CI caught something no local tier could

Run 17347: check green, E2E — webkit failed — and it failed on my
own spec rather than on the app.

[webkit] the desktop bar is untouched › keeps them exactly the size they were
  - "33x21"   (expected, measured in Chromium)
  + "36x24"   (received, WebKit)

WebKit draws the same button 36x24 where Chromium draws 33x21. A
button's box comes from the UA stylesheet when the author sets nothing,
and what each UA sets is its own business — so the literal was asserting
Chromium, not "unchanged". Nothing was wrong with the build.

Fixed in e3b64f9 by asserting the mechanism instead, which is the
same move queue-as-a-screen.spec.ts makes about containment:

• min-width and min-height compute to 0px
• the font-size still equals that of a bare <button> probed in the
  same page — the UA's, not the shell's
• all five boxes are identical, which is what says the desktop is
  neither sized context

Checked that it still bites: re-introduced the font-size: inherit
regression and it fails in Chromium, naming the assertion. The literal
form could only be checked by hand, and only in one engine.

Two things worth keeping out of this, both now in .planning/NOTES.md:
an absolute pixel size is engine-specific and does not belong in an
assertion about our changes; and this is the second time in two
sessions that CI's WebKit was the only tier that could see something,
which is the argument for checking that step ran rather than trusting
the run's conclusion.

make e2e locally: 220 passed after the fix.

## CI caught something no local tier could Run 17347: `check` green, **`E2E — webkit` failed** — and it failed on my own spec rather than on the app. ``` [webkit] the desktop bar is untouched › keeps them exactly the size they were - "33x21" (expected, measured in Chromium) + "36x24" (received, WebKit) ``` **WebKit draws the same button 36x24 where Chromium draws 33x21.** A button's box comes from the UA stylesheet when the author sets nothing, and what each UA sets is its own business — so the literal was asserting Chromium, not "unchanged". Nothing was wrong with the build. Fixed in `e3b64f9` by asserting the *mechanism* instead, which is the same move `queue-as-a-screen.spec.ts` makes about containment: - `min-width` and `min-height` compute to `0px` - the font-size still equals that of a bare `<button>` probed in the same page — the UA's, not the shell's - all five boxes are identical, which is what says the desktop is neither sized context **Checked that it still bites**: re-introduced the `font-size: inherit` regression and it fails in Chromium, naming the assertion. The literal form could only be checked by hand, and only in one engine. Two things worth keeping out of this, both now in `.planning/NOTES.md`: an absolute pixel size is engine-specific and does not belong in an assertion about *our* changes; and this is the second time in two sessions that CI's WebKit was the only tier that could see something, which is the argument for checking that step *ran* rather than trusting the run's conclusion. `make e2e` locally: **220 passed** after the fix.

logan merged commit fd71ef53c5 into main 2026-08-21 04:14:40 +00:00

Sign in to join this conversation.

Reviewers

No Reviewers

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

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

logan yonlu

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: yonlu/yellowjacket#173