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

Desktop: "Want track" on an album's tracklist appears to do nothing, and only shows on hover #33

New Issue
Closed
opened 2026-08-18 05:56:10 +00:00 by logan · 0 comments
logan commented 2026-08-18 05:56:10 +00:00
Collaborator
Copy Link
Copy Source

Report

Explore → album → click the request badge on a track: nothing appears to happen. Wanting the whole album works. The track does show up in the Downloads tab, so this looks like a UI-only bug. Separately, the per-track request buttons should not be hover-revealed — they should just be there.

Findings

Root cause is almost certainly a missing re-render:

  • explore-album-details.ts:723-729 subscribes to downloadStore but the callback only assigns this.canDownload = downloadStore.available. That value does not change when a request is added, so Lit sees no state change and never re-renders.
  • The badge's status is computed at render time by libraryStatusFor(false, track.mbid) (utils/library-status.ts), which reads downloadStore.requestFor(mbid) — so the correct queued state exists in the store and is simply never re-read.
  • The album header's own "Want this" button works because it is driven by fields the component does update (downloadStore.isRequested(...) read in a path that does re-render, ~lines 2666-2715).

Hover-only styling is at ~lines 677-693: .track-row .track-request { opacity: 0 }, raised on :hover/:focus-within.

Direction

  1. In the downloadStore subscription, bump a state counter (or store the request map) so a request change re-renders the tracklist.
  2. Drop the opacity: 0 — make the badge always visible. Note the badge is a <button> only where request-mbid is passed and the entity is not owned, so always-visible does not add tab stops on owned rows.
  3. Add a regression spec: click the badge, assert it becomes queued, without a reload.
**Report** Explore → album → click the request badge on a track: nothing appears to happen. Wanting the whole album works. The track *does* show up in the Downloads tab, so this looks like a UI-only bug. Separately, the per-track request buttons should not be hover-revealed — they should just be there. **Findings** Root cause is almost certainly a missing re-render: - `explore-album-details.ts:723-729` subscribes to `downloadStore` but the callback only assigns `this.canDownload = downloadStore.available`. That value does not change when a request is added, so Lit sees no state change and never re-renders. - The badge's status is computed at render time by `libraryStatusFor(false, track.mbid)` (`utils/library-status.ts`), which reads `downloadStore.requestFor(mbid)` — so the correct `queued` state exists in the store and is simply never re-read. - The album header's own "Want this" button works because it is driven by fields the component does update (`downloadStore.isRequested(...)` read in a path that does re-render, ~lines 2666-2715). Hover-only styling is at ~lines 677-693: `.track-row .track-request { opacity: 0 }`, raised on `:hover`/`:focus-within`. **Direction** 1. In the `downloadStore` subscription, bump a state counter (or store the request map) so a request change re-renders the tracklist. 2. Drop the `opacity: 0` — make the badge always visible. Note the badge is a `<button>` only where `request-mbid` is passed and the entity is not owned, so always-visible does not add tab stops on owned rows. 3. Add a regression spec: click the badge, assert it becomes `queued`, without a reload.
logan self-assigned this 2026-08-18 15:02:05 +00:00
logan closed this issue 2026-08-18 16:18:37 +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/Downloads Area/Explore Kind/Bug Platform/Desktop
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#33