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

Android: the seek bar's drag target is 6px tall #187

New Issue
Closed
opened 2026-08-21 19:40:14 +00:00 by logan · 1 comment
logan commented 2026-08-21 19:40:14 +00:00
Collaborator
Copy Link
Copy Source

Report

On now-playing-view — the screen that exists so a phone has somewhere
to seek from — the seek bar's slider is 261x6 CSS px. Six pixels is
the whole of the drag target, on the app's primary seeking affordance,
on a touch device.

Measured on the reference device (TLP301, Android 14, Chrome 113,
424x439) with a track loaded:
wa-slider host 261x6
its --track-size 6px
the thumb 22x22
the remaining-time button beside it 59x19

Findings

  • The thickening that exists is real but stops well short.
    seek-bar's own stylesheet already raises the track below the phone
    breakpoint, and the value it raises it to is 6px. The comment on
    now-playing-view explains why the size is set there rather than
    passed in — the track size lives on the wa-slider inside its shadow
    root — so the mechanism is right and only the number is wrong.
  • The thumb is not a rescue. It is 22x22 and overflows the host, so
    grabbing the thumb works at about half the floor; a tap anywhere
    else on the track to seek has 6px to land in. Those are the two
    gestures a seek bar has and both are under 44.
  • This is a hit area, not a thickness, which is why it is not
    filed with the rest of the small controls (#186). A 44px-thick
    progress bar would be wrong-looking and would cost the album art the
    vertical space #51 just spent an issue recovering. What is wanted is
    a transparent target around a thin painted track — the two are
    allowed to differ, and a slider is the clearest case where they
    should.
  • Untested claim worth checking before choosing a number: whether
    Web Awesome's slider takes pointer events on the host or on its inner
    track div decides whether padding on the host is enough or whether
    the target has to be built around it.

Direction

Give the slider a pointer target of at least 44px in height without
changing the painted track, and check that the surrounding flex row
does not grow by the difference — now-playing-view's budget is fixed
and #51 measured every pixel of it. The same control is in the desktop
bottom bar, where the current thickness is correct, so whatever is done
here should be keyed the way the existing thickening already is.

**Report** On `now-playing-view` — the screen that exists so a phone has somewhere to seek from — the seek bar's slider is **261x6 CSS px**. Six pixels is the whole of the drag target, on the app's primary seeking affordance, on a touch device. Measured on the reference device (TLP301, Android 14, Chrome 113, 424x439) with a track loaded: | | | |---|---| | `wa-slider` host | **261x6** | | its `--track-size` | **6px** | | the thumb | 22x22 | | the remaining-time button beside it | **59x19** | **Findings** - **The thickening that exists is real but stops well short.** `seek-bar`'s own stylesheet already raises the track below the phone breakpoint, and the value it raises it *to* is 6px. The comment on `now-playing-view` explains why the size is set there rather than passed in — the track size lives on the `wa-slider` inside its shadow root — so the mechanism is right and only the number is wrong. - **The thumb is not a rescue.** It is 22x22 and overflows the host, so grabbing the thumb works at about half the floor; a *tap* anywhere else on the track to seek has 6px to land in. Those are the two gestures a seek bar has and both are under 44. - **This is a hit area, not a thickness**, which is why it is not filed with the rest of the small controls (#186). A 44px-thick progress bar would be wrong-looking and would cost the album art the vertical space #51 just spent an issue recovering. What is wanted is a transparent target around a thin painted track — the two are allowed to differ, and a slider is the clearest case where they should. - Untested claim worth checking before choosing a number: whether Web Awesome's slider takes pointer events on the host or on its inner track div decides whether padding on the host is enough or whether the target has to be built around it. **Direction** Give the slider a pointer target of at least 44px in height without changing the painted track, and check that the surrounding flex row does not grow by the difference — `now-playing-view`'s budget is fixed and #51 measured every pixel of it. The same control is in the desktop bottom bar, where the current thickness is correct, so whatever is done here should be keyed the way the existing thickening already is.
logan self-assigned this 2026-08-21 22:00:08 +00:00
logan added the
Status
In Progress
 label 2026-08-21 22:00:09 +00:00
logan commented 2026-08-21 22:00:09 +00:00
Author
Collaborator
Copy Link
Copy Source

Taking this. Branch 187-seek-bar-hit-area.

One correction before starting, because it changes what the fix is.
The Findings say the thickening below the phone breakpoint "is real but
stops well short" at 6px. It is not real: seek-bar's stylesheet sets
--track-size: 12px inside @media (max-width: 599px) and then
--track-size: 6px in a plain wa-slider rule written after it. A
media query adds no specificity, so the plain rule wins at every width
and the phone rule has never applied. That is exactly the trap
CLAUDE.md documents for index.css ("the phone section is last on
purpose"), reproduced inside a component's own stylesheet -- and it is
why the measurement says 6 where the source says 12.

So there are two things here, and the second is the issue as filed:
the dead rule, and the fact that 12px would still be under the floor.

Plan, in the Direction's order:

  1. Settle the untested claim on the device first -- whether wa-slider
    takes pointer events on the host or on an inner track div, since
    that decides whether padding the host is enough or whether the
    target has to be built around it.
  2. Give the pointer target >=44px without changing the painted track,
    keyed the way the existing thickening already is.
  3. Check the flex row does not grow by the difference: #51 measured
    every pixel of now-playing-view's budget and #64 has since spent
    some of it.
Taking this. Branch `187-seek-bar-hit-area`. **One correction before starting, because it changes what the fix is.** The Findings say the thickening below the phone breakpoint "is real but stops well short" at 6px. It is not real: `seek-bar`'s stylesheet sets `--track-size: 12px` inside `@media (max-width: 599px)` and then `--track-size: 6px` in a plain `wa-slider` rule **written after it**. A media query adds no specificity, so the plain rule wins at every width and the phone rule has never applied. That is exactly the trap CLAUDE.md documents for `index.css` ("the phone section is last on purpose"), reproduced inside a component's own stylesheet -- and it is why the measurement says 6 where the source says 12. So there are two things here, and the second is the issue as filed: the dead rule, and the fact that 12px would still be under the floor. Plan, in the Direction's order: 1. Settle the untested claim on the device first -- whether `wa-slider` takes pointer events on the host or on an inner track div, since that decides whether padding the host is enough or whether the target has to be built around it. 2. Give the pointer target >=44px without changing the painted track, keyed the way the existing thickening already is. 3. Check the flex row does not grow by the difference: #51 measured every pixel of `now-playing-view`'s budget and #64 has since spent some of it.
logan closed this issue 2026-08-21 22:25:52 +00:00
gitea-actions bot removed the
Status
In Progress
 label 2026-08-21 22:26:01 +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
High
2
Reviewed
Confirmed
1
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
logan yonlu
No Assignees logan
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: yonlu/yellowjacket#187