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

The top bar overflows by 11px at 600x600, the bottom of the Compact band #143

New Issue
Closed
opened 2026-08-19 22:01:59 +00:00 by logan · 2 comments
logan commented 2026-08-19 22:01:59 +00:00
Collaborator
Copy Link
Copy Source

Report

At exactly 600×600 — the bottom of the Compact band #24 committed
to — the shell is 611px wide inside a 600px viewport, so 11px of it
sits behind overflow-x: auto and the window grows a horizontal
scrollbar. The promise that "no action is ever unreachable at any
supported size", and layout-overflow.spec.ts's own subject, both say
this should not happen.

Measured (make dev-headless SEED=default, 600×600, no local
changes to the header):

header.top-bar   clientWidth 600   scrollWidth 611
search-bar       width 248         right edge 611

So the overflowing child is the search box. .top-bar search-bar is
flex: 0 1 320px and search-bar's own stylesheet floors it at 200px;
at 600px the title, the library filter and the job indicator leave it
less than that and it refuses to shrink further, which is the floor
doing exactly what it was written to do — there is simply no width left
to give it.

Why no spec sees it. layout-overflow.spec.ts checks 1440×900,
900×600 and 800×600 plus the phone widths, and it is right to: 900 is
the narrowest content area a desktop width produces, which is the
case that argument was about. But the narrowest header is a
different question with a different answer, and 600 — the first width
at which the phone layout has not yet taken over — is where it lands.
600×600 is not in the list.

Direction

Add 600×600 to layout-overflow.spec.ts's viewport list first, so the
defect is pinned before it is fixed. Then give the header the same
treatment #69 gave page-header: below some width one of its four
children has to yield. Candidates, cheapest first — the library filter
is already display: none below 600 and could go at 700; the title
could truncate (it is the brand, and the window title bar says the same
thing); or the search box could collapse to an icon that expands, which
is what #57 asks for on the phone anyway and would make this one
mechanism rather than two.

Found while measuring #6, which adds two buttons to this bar. Those
are hidden below 900 for exactly this reason — the pre-existing 11px
became 95px with them — so the two are related but this one stands
alone and predates it.

**Report** At exactly 600×600 — the bottom of the **Compact** band #24 committed to — the shell is 611px wide inside a 600px viewport, so 11px of it sits behind `overflow-x: auto` and the window grows a horizontal scrollbar. The promise that "no action is ever unreachable at any supported size", and `layout-overflow.spec.ts`'s own subject, both say this should not happen. **Measured** (`make dev-headless SEED=default`, 600×600, no local changes to the header): ``` header.top-bar clientWidth 600 scrollWidth 611 search-bar width 248 right edge 611 ``` So the overflowing child is the search box. `.top-bar search-bar` is `flex: 0 1 320px` and `search-bar`'s own stylesheet floors it at 200px; at 600px the title, the library filter and the job indicator leave it less than that and it refuses to shrink further, which is the floor doing exactly what it was written to do — there is simply no width left to give it. **Why no spec sees it.** `layout-overflow.spec.ts` checks 1440×900, 900×600 and 800×600 plus the phone widths, and it is right to: 900 is the *narrowest content area* a desktop width produces, which is the case that argument was about. But the narrowest **header** is a different question with a different answer, and 600 — the first width at which the phone layout has not yet taken over — is where it lands. 600×600 is not in the list. **Direction** Add 600×600 to `layout-overflow.spec.ts`'s viewport list first, so the defect is pinned before it is fixed. Then give the header the same treatment #69 gave `page-header`: below some width one of its four children has to yield. Candidates, cheapest first — the library filter is already `display: none` below 600 and could go at 700; the title could truncate (it is the brand, and the window title bar says the same thing); or the search box could collapse to an icon that expands, which is what #57 asks for on the phone anyway and would make this one mechanism rather than two. Found while measuring #6, which adds two buttons to this bar. Those are hidden below 900 for exactly this reason — the pre-existing 11px became 95px with them — so the two are related but this one stands alone and predates it.
logan commented 2026-08-20 01:08:43 +00:00
Author
Collaborator
Copy Link
Copy Source

Re-measured on main at 6e7e349 (after #6, #72, #25 and #27), and
the 11px is the best case.

make dev-headless SEED=default, header.top-bar client vs scroll:

viewport job indicator client → scroll
600×600 hidden 600 → 611
600×600 visible 600 → 771
620×600 hidden 620 → 620
899×600 hidden 899 → 899
900×600 hidden 900 → 900

Two things that were not in the report:

The overflow is 171px, not 11px, whenever anything is happening.
job-indicator is hidden while idle and 144px wide when it is not,
so the bar overflows by 11px sitting still and by 171px during a scan,
an index build or a download — which is exactly when a user has reason
to look at it. The idle case is the one that got measured because a
seeded app that has finished scanning is idle by the time you resize
it; it took ~8 seconds of settling for the number to drop to 11.

The band is narrow: 600–610. At 620 the bar fits, and it fits at
every width up to 900 where nav-history appears (68px) and it still
fits. So this is not "the header is too crowded from 900 down", it is
one specific corner — which is worth knowing before reaching for a
general responsive rework, and is an argument for fixing it in a way
#48 can build on rather than a way #48 would discard.

The child measurements at 600 are unchanged from the report:
hgroup:152 nav-history:0 library-filter:148 search-bar:248 job-indicator:0.

**Re-measured on `main` at `6e7e349` (after #6, #72, #25 and #27), and the 11px is the *best* case.** `make dev-headless SEED=default`, `header.top-bar` client vs scroll: | viewport | job indicator | client → scroll | |---|---|---| | 600×600 | hidden | 600 → **611** | | 600×600 | visible | 600 → **771** | | 620×600 | hidden | 620 → 620 | | 899×600 | hidden | 899 → 899 | | 900×600 | hidden | 900 → 900 | Two things that were not in the report: **The overflow is 171px, not 11px, whenever anything is happening.** `job-indicator` is `hidden` while idle and 144px wide when it is not, so the bar overflows by 11px sitting still and by 171px during a scan, an index build or a download — which is exactly when a user has reason to look at it. The idle case is the one that got measured because a seeded app that has finished scanning is idle by the time you resize it; it took ~8 seconds of settling for the number to *drop* to 11. **The band is narrow: 600–610.** At 620 the bar fits, and it fits at every width up to 900 where `nav-history` appears (68px) and it still fits. So this is not "the header is too crowded from 900 down", it is one specific corner — which is worth knowing before reaching for a general responsive rework, and is an argument for fixing it in a way #48 can build on rather than a way #48 would discard. The child measurements at 600 are unchanged from the report: `hgroup:152 nav-history:0 library-filter:148 search-bar:248 job-indicator:0`.
logan self-assigned this 2026-08-20 01:11:02 +00:00
logan added the
Status
In Progress
 label 2026-08-20 01:11:03 +00:00
logan commented 2026-08-20 01:11:03 +00:00
Author
Collaborator
Copy Link
Copy Source

Claiming this. Branch: fix/143-top-bar-fits-its-window.

Approach. The Direction's order, literally: 600×600 goes into
layout-overflow.spec.ts first and is watched to fail, plus the
indicator-visible case — the 171px measured in the comment above is
the real defect and nothing in the suite has ever measured a layout with
a job running. /__test/emit forces JobsChanged without staging a
scan.

Then the #69 treatment, measured rather than breakpointed, for a
reason specific to this bar: library-filter's width is its content,
so a library called "Music from the external drive" is wider than the
fixture's and any breakpoint is right for exactly one library name. A
ResizeObserver over .top-bar that hides the lowest-priority child
until it fits is the mechanism page-header already has a worked
example of.

Search-collapses-to-an-icon is deliberately out of scope. It is what
#57 wants on the phone and would be one mechanism instead of two — but
#57 is Status/Blocked behind #62, so building its modal now is
building it without the thing that blocks it. The yield order will make
the search box the last thing to go, so #57 inherits a stated position
rather than an accident.

Claiming this. Branch: `fix/143-top-bar-fits-its-window`. **Approach.** The Direction's order, literally: 600×600 goes into `layout-overflow.spec.ts` first and is watched to fail, plus the **indicator-visible** case — the 171px measured in the comment above is the real defect and nothing in the suite has ever measured a layout with a job running. `/__test/emit` forces `JobsChanged` without staging a scan. Then the #69 treatment, **measured rather than breakpointed**, for a reason specific to this bar: `library-filter`'s width is its *content*, so a library called "Music from the external drive" is wider than the fixture's and any breakpoint is right for exactly one library name. A ResizeObserver over `.top-bar` that hides the lowest-priority child until it fits is the mechanism `page-header` already has a worked example of. **Search-collapses-to-an-icon is deliberately out of scope.** It is what #57 wants on the phone and would be one mechanism instead of two — but #57 is `Status/Blocked` behind #62, so building its modal now is building it without the thing that blocks it. The yield order will make the search box the *last* thing to go, so #57 inherits a stated position rather than an accident.
logan closed this issue 2026-08-20 02:11:54 +00:00
gitea-actions bot removed the
Status
In Progress
 label 2026-08-20 02:12:06 +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/Shell-Nav Kind/Bug 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#143