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

The phone's context sheet is taller than the screen, and its last item is below the fold #207

New Issue
Closed
opened 2026-08-23 09:57:51 +00:00 by logan · 2 comments
logan commented 2026-08-23 09:57:51 +00:00
Collaborator
Copy Link
Copy Source

Report

On the reference device's viewport (424x439) the bottom-sheet context
menu is now taller than the screen, and the last item is below the
fold with nothing on screen to say the list continues. On the track
list that last item is Remove from Library.

Reproduction

make dev-headless SEED=default
playwright-cli -s=yj open http://localhost:34115
playwright-cli -s=yj resize 424 439
# navigate to Tracks, right-click (or hold) a row, then:
playwright-cli -s=yj eval "() => {
  const tl = document.querySelector('track-list').shadowRoot;
  const items = [...tl.querySelectorAll('wa-dropdown-item')];
  return {count: items.length,
          lastBottom: Math.round(items.at(-1).getBoundingClientRect().bottom),
          vh: window.innerHeight};
}"

Measured 2026-08-23, one row selected:

menu items first item top last item bottom
queue panel 7 95 431
track list 8 86 470

Findings

  • It is not unreachable, which is why this is not Priority/High.
    The sheet is a wa-dialog whose body is overflow-y: auto
    (scrollHeight 412 against clientHeight 373), and scrolling it
    39px brings "Remove from Library" fully into view (383-431). What is
    missing is the affordance: nothing indicates there is more.
  • The limit was already reached. contextMenuStyles gives a sheet
    48px rows (#56/#60), so seven of them is 364px in a 373px body — the
    queue's menu fits with 8px to spare and the track list's fitted
    exactly. #67 added the item that crossed it; any item added to any of
    the fourteen menus would have.
  • It is a property of the shared sheet
    (components/menu-surface/), not of any one menu's items, which is
    why it is filed rather than answered inside #67.

Direction

Something on the sheet that says it scrolls — a fade or a shortened
last row are the usual two — or a max height that makes the cut
obvious. Deliberately not "fewer items": the items are each somewhere
else's only route on a phone, which is what #67 is about.

Measurement recorded in .planning/NOTES.md (2026-08-23).

**Report** On the reference device's viewport (424x439) the bottom-sheet context menu is now taller than the screen, and the last item is below the fold with nothing on screen to say the list continues. On the track list that last item is **Remove from Library**. **Reproduction** ``` make dev-headless SEED=default playwright-cli -s=yj open http://localhost:34115 playwright-cli -s=yj resize 424 439 # navigate to Tracks, right-click (or hold) a row, then: playwright-cli -s=yj eval "() => { const tl = document.querySelector('track-list').shadowRoot; const items = [...tl.querySelectorAll('wa-dropdown-item')]; return {count: items.length, lastBottom: Math.round(items.at(-1).getBoundingClientRect().bottom), vh: window.innerHeight}; }" ``` Measured 2026-08-23, one row selected: | menu | items | first item top | last item bottom | |---|---|---|---| | queue panel | 7 | 95 | 431 | | track list | 8 | 86 | **470** | **Findings** - It is **not unreachable**, which is why this is not `Priority/High`. The sheet is a `wa-dialog` whose body is `overflow-y: auto` (`scrollHeight` 412 against `clientHeight` 373), and scrolling it 39px brings "Remove from Library" fully into view (383-431). What is missing is the affordance: nothing indicates there is more. - **The limit was already reached.** `contextMenuStyles` gives a sheet 48px rows (#56/#60), so seven of them is 364px in a 373px body — the queue's menu fits with 8px to spare and the track list's fitted exactly. #67 added the item that crossed it; any item added to any of the fourteen menus would have. - It is a property of the shared sheet (`components/menu-surface/`), not of any one menu's items, which is why it is filed rather than answered inside #67. **Direction** Something on the sheet that says it scrolls — a fade or a shortened last row are the usual two — or a max height that makes the cut obvious. Deliberately not "fewer items": the items are each somewhere else's only route on a phone, which is what #67 is about. Measurement recorded in `.planning/NOTES.md` (2026-08-23).
logan self-assigned this 2026-08-23 10:33:19 +00:00
logan added the
Status
In Progress
 label 2026-08-23 10:33:19 +00:00
logan commented 2026-08-23 10:33:20 +00:00
Author
Collaborator
Copy Link
Copy Source

Picking this up.

Taking the Direction's first option: a scroll shadow pinned to the
sheet body's bottom edge, revealed and hidden by
background-attachment: local rather than by a scroll listener, in the
one wa-dialog::part(body) rule that already owns the scroller.

The 85vh cap stays — menu-surface's own comment says a sheet covering
the whole screen is a page, not a sheet — so the affordance is what
changes, not the height.

Picking this up. Taking the Direction's first option: **a scroll shadow pinned to the sheet body's bottom edge**, revealed and hidden by `background-attachment: local` rather than by a scroll listener, in the one `wa-dialog::part(body)` rule that already owns the scroller. The 85vh cap stays — `menu-surface`'s own comment says a sheet covering the whole screen is a page, not a sheet — so the affordance is what changes, not the height.
logan commented 2026-08-23 11:03:11 +00:00
Author
Collaborator
Copy Link
Copy Source

PR #209 — #209 — CI green
(check and e2e).

Took the Direction's first option. The 85vh cap stays; the fade is two
background layers on wa-dialog::part(body), and the pair of
attachments is what makes it conditional — a cover of the sheet's own
colour painted at the end of the content (local) over a shadow pinned
to the box (scroll), so it is absent on a menu that fits, present the
moment one does not, and gone again at the end of the list. No scroll
listener, and nothing reaching into wa-dialog's shadow root.

The other two options were ruled out rather than skipped: a shortened
last row and a max height that makes the cut obvious both need
height mod 48, which CSS cannot express — and the case that
reproduces on main is already a cut on a row boundary, which is the
worst version of the complaint rather than a mild one.

Measured, x=300, dark ramp: flat 52,58,64 before; 50,56,62 → 22,24,27
with more below; flat again at the end of the list; flat at 424x439
where the menu fits and nothing is drawn. Light ramp checked too — the
curve is steep rather than linear because a scrim over a menu row is
that row's text surface, so the 4.5:1 rule reaches it; the last label
measures 9.9:1 on #e9ecef. Table in .planning/NOTES.md.

One note for whoever reads this next: no e2e spec was added. The
only viewport on main where a menu overflows is 424x360, because
main does not yet carry #67's eighth item — at 424x439 the track
list's seven items are scrollHeight 364 against clientHeight 364,
fitting exactly. A spec pinned to 424x360 would be about the fixture
rather than the app. Once #67 merges the menu overflows at the real
424x439 and the spec becomes worth writing.

PR #209 — https://git.ljones.me/yonlu/yellowjacket/pulls/209 — CI green (`check` and `e2e`). Took the Direction's first option. The 85vh cap stays; the fade is two background layers on `wa-dialog::part(body)`, and the *pair of attachments* is what makes it conditional — a cover of the sheet's own colour painted at the end of the content (`local`) over a shadow pinned to the box (`scroll`), so it is absent on a menu that fits, present the moment one does not, and gone again at the end of the list. No scroll listener, and nothing reaching into `wa-dialog`'s shadow root. The other two options were ruled out rather than skipped: a shortened last row and a max height that makes the cut obvious both need `height mod 48`, which CSS cannot express — and the case that reproduces on `main` is already a cut *on* a row boundary, which is the worst version of the complaint rather than a mild one. **Measured**, x=300, dark ramp: flat 52,58,64 before; 50,56,62 → 22,24,27 with more below; flat again at the end of the list; flat at 424x439 where the menu fits and nothing is drawn. Light ramp checked too — the curve is steep rather than linear because a scrim over a menu row is that row's text surface, so the 4.5:1 rule reaches it; the last label measures 9.9:1 on `#e9ecef`. Table in `.planning/NOTES.md`. One note for whoever reads this next: **no e2e spec was added.** The only viewport on `main` where a menu overflows is 424x360, because `main` does not yet carry #67's eighth item — at 424x439 the track list's seven items are `scrollHeight` 364 against `clientHeight` 364, fitting exactly. A spec pinned to 424x360 would be about the fixture rather than the app. Once #67 merges the menu overflows at the real 424x439 and the spec becomes worth writing.
logan closed this issue 2026-08-25 16:39:44 +00:00
gitea-actions bot removed the
Status
In Progress
 label 2026-08-25 16:42:45 +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/Design Kind/Bug Platform/Android
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#207