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

Desktop: show a volume slider in the bottom bar by default instead of a click-to-open popup #42

New Issue
Closed
opened 2026-08-18 05:57:03 +00:00 by logan · 1 comment
logan commented 2026-08-18 05:57:03 +00:00
Collaborator
Copy Link
Copy Source

Report

Having to click open and click closed for volume is annoying. Make an always-visible small slider in the bottom bar the default, with the popup behaviour available as a setting.

Findings

  • frontend/src/components/audio-player/volume-control/ toggles a .volume-popup on click and installs a document click listener to close it (~lines 127-159, 198-222).
  • Width is the reason it is a popup: the bottom bar already declares what it drops at phone width, and the volume control is on that list. An inline slider needs a floor width and must stand down below some breakpoint (on Android it should disappear entirely — see the Android volume issue).
  • wa-slider's accessible name comes from its label (the host's aria-label is outranked by an internal empty <label>); styles/wa-slider-label.css.ts hides it, and note that #slider takes an 8px margin the moment a label exists, growing the bar 6px → 14px and moving the transport with it. Any relayout here must re-check that.

Direction

Inline slider by default at desktop widths, popup below the breakpoint and whenever the setting says so. One config key, default "inline".

**Report** Having to click open and click closed for volume is annoying. Make an always-visible small slider in the bottom bar the default, with the popup behaviour available as a setting. **Findings** - `frontend/src/components/audio-player/volume-control/` toggles a `.volume-popup` on click and installs a document click listener to close it (~lines 127-159, 198-222). - Width is the reason it is a popup: the bottom bar already declares what it drops at phone width, and the volume control is on that list. An inline slider needs a floor width and must stand down below some breakpoint (on Android it should disappear entirely — see the Android volume issue). - `wa-slider`'s accessible name comes from its `label` (the host's `aria-label` is outranked by an internal empty `<label>`); `styles/wa-slider-label.css.ts` hides it, and note that `#slider` takes an 8px margin the moment a label exists, growing the bar 6px → 14px and moving the transport with it. Any relayout here must re-check that. **Direction** Inline slider by default at desktop widths, popup below the breakpoint and whenever the setting says so. One config key, default "inline".
logan self-assigned this 2026-08-20 03:38:43 +00:00
logan added the
Status
In Progress
 label 2026-08-20 03:38:44 +00:00
logan commented 2026-08-20 03:38:44 +00:00
Author
Collaborator
Copy Link
Copy Source

Claiming this with #23, as one pass. Branch:
feat/42-inline-volume-and-centred-transport.

Why together rather than in sequence. This issue's own findings say
giving wa-slider a label takes #slider's margin from 0 to 8px, which
grows the bar 6px to 14px and moves the transport with it — and the
transport's position is exactly what #23 is about. Doing them separately
means measuring the bar twice and throwing the first measurement away.

Approach. #23's Direction is the mechanism for both: a three-column
grid with equal-width outer columns and min-width: 0, so the centre is
genuinely centred rather than drifting as the metadata changes width,
and the inline slider has a column to live in that does not push the
transport off-centre.

services/top-bar-fit.ts (#143) is the worked example for the part that
follows: what a bar drops when it runs out of room. I expect the answer
here to be simpler — the bottom bar already declares what it drops at
phone width — but the same rule applies, that what yields must not be an
action.

#64 is adjacent and I am not doing it here. The soft relation on #73
is that both touch volume-control and the answers are opposite: inline
it on desktop, remove it on Android. Standing the inline slider down
below 600px is not #64 — that issue asks for absent-on-Android including
tablet widths, plus pinning the internal level at 1.0 without disturbing
OnDuck. I will note on it what this pass leaves in place.

Verification: make ui-test, make ui-visual baselines, and
screenshots at 800px, 900px and 200% text, since the cosmetic half is
the whole point and no assertion sees it.

Claiming this with #23, as one pass. Branch: `feat/42-inline-volume-and-centred-transport`. **Why together rather than in sequence.** This issue's own findings say giving `wa-slider` a label takes `#slider`'s margin from 0 to 8px, which **grows the bar 6px to 14px and moves the transport with it** — and the transport's position is exactly what #23 is about. Doing them separately means measuring the bar twice and throwing the first measurement away. **Approach.** #23's Direction is the mechanism for both: a three-column grid with equal-width outer columns and `min-width: 0`, so the centre is genuinely centred rather than drifting as the metadata changes width, and the inline slider has a column to live in that does not push the transport off-centre. `services/top-bar-fit.ts` (#143) is the worked example for the part that follows: what a bar drops when it runs out of room. I expect the answer here to be simpler — the bottom bar already declares what it drops at phone width — but the same rule applies, that what yields must not be an action. **#64 is adjacent and I am not doing it here.** The soft relation on #73 is that both touch `volume-control` and the answers are opposite: inline it on desktop, remove it on Android. Standing the inline slider down below 600px is not #64 — that issue asks for absent-on-Android including tablet widths, plus pinning the internal level at 1.0 without disturbing `OnDuck`. I will note on it what this pass leaves in place. Verification: `make ui-test`, `make ui-visual` baselines, and screenshots at 800px, 900px and 200% text, since the cosmetic half is the whole point and no assertion sees it.
logan closed this issue 2026-08-20 05:22:04 +00:00
gitea-actions bot removed the
Status
In Progress
 label 2026-08-20 05:23:33 +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/Enhancement Platform/Desktop
Priority
Medium
3
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#42