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

Desktop: single-click should select tracks in album/detail track lists, not just the Tracks tab #5

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

Report

On the main Tracks tab a single click selects a row, and ctrl/shift extend the selection. Every other list of tracks (album detail, and the other detail views) does not do this, so there is no way to multi-select a few tracks to add to the queue.

Findings

  • frontend/src/components/track-list/track-list.ts has the full selection model (SelectionController, shift-extend, ctrl-toggle) and is pinned by its own tests.
  • frontend/src/components/explore-album-details/explore-album-details.ts (renderTracklist, ~line 3080) renders rows with only @dblclick, @contextmenu and @keydown — no click/selection handling at all.
  • queue-panel already wires SelectionController (see separate issue about it not behaving).

Direction

Reuse utils/selection-controller.ts in the album detail tracklist (and the playlist/genre/artist detail lists that lack it) so selection semantics are identical everywhere. The context menu already asks "how much is selected" — one row means "play from here", several means "those tracks" — so the menu behaviour follows for free once selection exists.

Note the album page's own rule: the index is into the owned file paths, not into the displayed rows (dimmed rows are not in the queue), so selection keys should stay file paths where a file exists.

**Report** On the main Tracks tab a single click selects a row, and ctrl/shift extend the selection. Every other list of tracks (album detail, and the other detail views) does not do this, so there is no way to multi-select a few tracks to add to the queue. **Findings** - `frontend/src/components/track-list/track-list.ts` has the full selection model (`SelectionController`, shift-extend, ctrl-toggle) and is pinned by its own tests. - `frontend/src/components/explore-album-details/explore-album-details.ts` (`renderTracklist`, ~line 3080) renders rows with only `@dblclick`, `@contextmenu` and `@keydown` — no click/selection handling at all. - `queue-panel` already wires `SelectionController` (see separate issue about it not behaving). **Direction** Reuse `utils/selection-controller.ts` in the album detail tracklist (and the playlist/genre/artist detail lists that lack it) so selection semantics are identical everywhere. The context menu already asks "how much is selected" — one row means "play from here", several means "those tracks" — so the menu behaviour follows for free once selection exists. Note the album page's own rule: the index is into the *owned file paths*, not into the displayed rows (dimmed rows are not in the queue), so selection keys should stay file paths where a file exists.
logan commented 2026-08-20 02:59:12 +00:00
Author
Collaborator
Copy Link
Copy Source

A finding from #43 that lands on this issue before it starts.

This issue's plan is to reuse utils/selection-controller.ts in the
album detail tracklist and the other detail lists. Worth knowing first:
explore-link deliberately stops the click's propagation, in its own
words "the row must not also treat it as a selection". So adding the
controller to a list does not give that list selection on its names
— a click on a track, album or artist name will navigate and select
nothing, exactly as it does in track-list and queue-panel today.

Measured on the running app, by asking elementFromPoint what is under
each x across a row at three heights:

list link coverage
queue panel 12%
track list 21%

So on the Tracks tab roughly a fifth of the row is not selectable, and
nobody has minded, because the row is wide and has five other columns.
explore-album-details's tracklist is the one to check before
copying the pattern: its rows are number / title / artist / duration,
so the two link columns are a much larger share of a much narrower row,
and the same 20% could be 50% there. Worth a hit-scan on that row
specifically once selection exists — the number is cheap to get and it
decides whether this is fine or whether the album page needs the names
demoted (which is #67's direction, one platform over).

The other half, also from #43: the queue's selection is pinned now
(e2e/specs/queue-selection.spec.ts), including both halves of the
explore-link exception. That file is the shape to copy for whatever
lists this issue adds selection to — in particular the bounded 500ms
assertion, since a virtualized list can repaint seconds late and a
default 5s poll cannot tell that from working.

**A finding from #43 that lands on this issue before it starts.** This issue's plan is to reuse `utils/selection-controller.ts` in the album detail tracklist and the other detail lists. Worth knowing first: **`explore-link` deliberately stops the click's propagation**, in its own words *"the row must not also treat it as a selection"*. So adding the controller to a list does **not** give that list selection on its names — a click on a track, album or artist name will navigate and select nothing, exactly as it does in `track-list` and `queue-panel` today. Measured on the running app, by asking `elementFromPoint` what is under each x across a row at three heights: | list | link coverage | |---|---| | queue panel | 12% | | track list | 21% | So on the Tracks tab roughly a fifth of the row is not selectable, and nobody has minded, because the row is wide and has five other columns. **`explore-album-details`'s tracklist is the one to check before copying the pattern**: its rows are number / title / artist / duration, so the two link columns are a much larger share of a much narrower row, and the same 20% could be 50% there. Worth a hit-scan on that row specifically once selection exists — the number is cheap to get and it decides whether this is fine or whether the album page needs the names demoted (which is #67's direction, one platform over). The other half, also from #43: the queue's selection is pinned now (`e2e/specs/queue-selection.spec.ts`), including both halves of the `explore-link` exception. That file is the shape to copy for whatever lists this issue adds selection to — in particular the bounded 500ms assertion, since a virtualized list can repaint *seconds* late and a default 5s poll cannot tell that from working.
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/Library-UI 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
1 Participants
Notifications
Due Date
No due date set.
Blocks
#8 Desktop: drag tracks from the album detail view onto the queue panel
yonlu/yellowjacket
Reference: yonlu/yellowjacket#5