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

Android: move inline entity links into the item's context menu #67

New Issue
Closed
opened 2026-08-18 06:00:07 +00:00 by logan · 3 comments
logan commented 2026-08-18 06:00:07 +00:00
Collaborator
Copy Link
Copy Source

Report

Tapping a small text link inside a row to reach an artist/album page is fiddly on a phone. On mobile, those inline links should not be links — the item's context menu should carry "Go to artist", "Go to album" and so on instead.

Findings

  • utils/explore-link.ts renders every track/album/artist name in the app and is what makes a name navigable. Its click handling is explicitly a desktop compromise: the navigation is held for one double-click interval and dropped if a second click arrives, because the title is the widest thing in a row and double-clicking a row plays it. On touch that produces a delay and an ambiguous target.
  • Rows deliberately do not know links exist, so making them plain text at phone widths is a change in one utility.
  • The menu items exist in some menus already; they must be added consistently — and with the bottom-sheet menu (separate issue) there is room for them.

Direction

explore-link renders plain text below the phone breakpoint; every row/card context menu gains "Go to artist" / "Go to album" / "Go to genre" where the entity is known. Keep the desktop behaviour untouched.

**Report** Tapping a small text link inside a row to reach an artist/album page is fiddly on a phone. On mobile, those inline links should not be links — the item's context menu should carry "Go to artist", "Go to album" and so on instead. **Findings** - `utils/explore-link.ts` renders every track/album/artist name in the app and is what makes a name navigable. Its click handling is explicitly a *desktop* compromise: the navigation is held for one double-click interval and dropped if a second click arrives, because the title is the widest thing in a row and double-clicking a row plays it. On touch that produces a delay and an ambiguous target. - Rows deliberately do not know links exist, so making them plain text at phone widths is a change in one utility. - The menu items exist in some menus already; they must be added consistently — and with the bottom-sheet menu (separate issue) there is room for them. **Direction** `explore-link` renders plain text below the phone breakpoint; every row/card context menu gains "Go to artist" / "Go to album" / "Go to genre" where the entity is known. Keep the desktop behaviour untouched.
logan removed the
Status
Blocked
1
 label 2026-08-21 07:26:44 +00:00
logan commented 2026-08-21 07:26:56 +00:00
Author
Collaborator
Copy Link
Copy Source

Unblocked: #60 merged in #176, so the sole dependency is closed and
Status/Blocked is off.

What landed that you inherit rather than have to build:
components/menu-surface/ is the one decision about where a menu is
drawn — a wa-popup above 600px, a wa-dialog bottom sheet below it —
and all fourteen menu call sites go through it, including the playlist
submenu, which stacks as a second sheet. contextMenuStyles carries
the 48px rows for all of them, so a new menu gets thumb-sized targets
by using the same .context-menu-panel markup and nothing else.

Two things worth knowing before you add a menu:

  • A bare <wa-popup> will fail the build, deliberately.
    frontend/test/components/menu-surface.test.ts sweeps the source and
    allows three files, each with a stated reason. A popup is clipped on
    the reference device by .main-panel's paint containment and no
    tier here can see that    , so the guard is a source sweep rather than a
    rendered assertion.
  • The device measurements are in .planning/NOTES.md, dated
    2026-08-21 — including the two that would otherwise cost a rebuild: a
    top-layer <dialog> really does escape paint containment from inside
    a view, and a native dialog's UA max-width is what makes a naive
    sheet come out 354px wide on a 424px screen.
**Unblocked**: #60 merged in #176, so the sole dependency is closed and `Status/Blocked` is off. What landed that you inherit rather than have to build: `components/menu-surface/` is the one decision about *where* a menu is drawn — a `wa-popup` above 600px, a `wa-dialog` bottom sheet below it — and all fourteen menu call sites go through it, including the playlist submenu, which stacks as a second sheet. `contextMenuStyles` carries the 48px rows for all of them, so a new menu gets thumb-sized targets by using the same `.context-menu-panel` markup and nothing else. Two things worth knowing before you add a menu: - **A bare `<wa-popup>` will fail the build**, deliberately. `frontend/test/components/menu-surface.test.ts` sweeps the source and allows three files, each with a stated reason. A popup is clipped on the reference device by `.main-panel`'s paint containment and *no tier here can see that*, so the guard is a source sweep rather than a rendered assertion. - **The device measurements are in `.planning/NOTES.md`**, dated 2026-08-21 — including the two that would otherwise cost a rebuild: a top-layer `<dialog>` really does escape paint containment from inside a view, and a native dialog's UA `max-width` is what makes a naive sheet come out 354px wide on a 424px screen.
logan self-assigned this 2026-08-23 09:36:18 +00:00
logan added the
Status
In Progress
 label 2026-08-23 09:36:18 +00:00
logan commented 2026-08-23 09:36:18 +00:00
Author
Collaborator
Copy Link
Copy Source

Taking this — it is Phase 4's next item in #73's sequence now that #63
has landed. Branch feat/67-entity-links-into-menus.

Approach, as far as it is decided before the code:

  • utils/explore-link.ts owns the rule, as the Findings ask: below the
    phone breakpoint a name renders as plain text rather than as a link.
  • Every row/card context menu whose row loses a link gains
    "Go to artist" / "Go to album" in its place, phone-only, so the
    desktop menus are untouched.
  • "Go to genre" is not in this, and the reason is that there is no
    genre link anywhere to lose: explore-link has no genreLink and no
    row renders one. Adding one would be new navigation rather than a
    replacement for something the phone took away, so it belongs in its
    own issue if it is wanted.
  • Three surfaces render a name with no menu to carry the
    destination     — now-playing-view, explore-album-details' header
    credit, and top-results-row. Suppressing those would take the
    action away entirely rather than move it, which plan 018's promise
    refuses, so they keep their links and say why in a comment.
Taking this — it is Phase 4's next item in #73's sequence now that #63 has landed. Branch `feat/67-entity-links-into-menus`. **Approach**, as far as it is decided before the code: - `utils/explore-link.ts` owns the rule, as the Findings ask: below the phone breakpoint a name renders as plain text rather than as a link. - Every row/card context menu whose row loses a link gains "Go to artist" / "Go to album" in its place, phone-only, so the desktop menus are untouched. - **"Go to genre" is not in this**, and the reason is that there is no genre link anywhere to lose: `explore-link` has no `genreLink` and no row renders one. Adding one would be new navigation rather than a replacement for something the phone took away, so it belongs in its own issue if it is wanted. - Three surfaces render a name with **no menu to carry the destination** — `now-playing-view`, `explore-album-details`' header credit, and `top-results-row`. Suppressing those would take the action away entirely rather than move it, which plan 018's promise refuses, so they keep their links and say why in a comment.
logan commented 2026-08-23 10:13:06 +00:00
Author
Collaborator
Copy Link
Copy Source

PR #208 — #208. CI
green on both engines (run 17663).

What landed against this issue:

  • utils/explore-link.ts renders a plain string below PHONE_QUERY,
    and utils/go-to-menu.ts draws "Go to Artist" / "Go to Album" under
    exactly that condition, from explore-link's own exported routing.
    Seven menus carry it: the track list, the queue, both playlist detail
    views, the album cards, Explore's cards and rows, and the artist
    page's top tracks.
  • Three surfaces keep their links and say why — now-playing-view,
    explore-album-details' header credit and top-results-row have no
    menu to carry the destination, so suppressing them would take the
    action away rather than move it.
  • No "Go to Genre", as flagged when claiming: no row renders a
    genre link, so there is nothing for the phone to take away and the
    item would be new navigation rather than a replacement. If it is
    wanted it should be its own issue.
  • track-list is the one list that gains rather than moves: its
    phone column set has always stacked title over artist as plain text,
    so those names were never links there.

Found while doing it, filed as #207: the track list's sheet is now
eight items and its last one ("Remove from Library") ends at y=470 in a
439px viewport. It is reachable — the sheet's body scrolls, measured
39px — but nothing says the list continues, and the limit was already
reached before this (seven 48px rows is 364px in a 373px body). It is a
property of menu-surface, not of these items.

**PR #208** — https://git.ljones.me/yonlu/yellowjacket/pulls/208. CI green on both engines (run 17663). What landed against this issue: - `utils/explore-link.ts` renders a plain string below `PHONE_QUERY`, and `utils/go-to-menu.ts` draws "Go to Artist" / "Go to Album" under exactly that condition, from `explore-link`'s own exported routing. Seven menus carry it: the track list, the queue, both playlist detail views, the album cards, Explore's cards and rows, and the artist page's top tracks. - Three surfaces keep their links and say why — `now-playing-view`, `explore-album-details`' header credit and `top-results-row` have no menu to carry the destination, so suppressing them would take the action away rather than move it. - **No "Go to Genre"**, as flagged when claiming: no row renders a genre link, so there is nothing for the phone to take away and the item would be new navigation rather than a replacement. If it is wanted it should be its own issue. - `track-list` is the one list that *gains* rather than moves: its phone column set has always stacked title over artist as plain text, so those names were never links there. **Found while doing it, filed as #207**: the track list's sheet is now eight items and its last one ("Remove from Library") ends at y=470 in a 439px viewport. It is reachable — the sheet's body scrolls, measured 39px — but nothing says the list continues, and the limit was already reached before this (seven 48px rows is 364px in a 373px body). It is a property of `menu-surface`, not of these items.
logan closed this issue 2026-08-25 16:51:16 +00:00
gitea-actions bot removed the
Status
In Progress
 label 2026-08-25 16:58:57 +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/Library-UI Kind/Enhancement Platform/Android
Priority
Medium
3
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.
Depends on
#60 Android: context menus should be a bottom sheet, not a popover that gets clipped
yonlu/yellowjacket
Reference: yonlu/yellowjacket#67