You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
bug(nav): Priority+ on /#/perf at ~1080px shows ONLY active pill — high-priority links vanish, More dropdown contains only active route (20th regression) #1391
Operator screenshot of staging at ~1080px-wide viewport on /#/perf: navbar shows ONLY the active-route pill ("Perf"). Brand + a few high-priority links should be visible inline; instead they're gone, AND clicking "More" only shows "Perf" (the active route) — not the missing links that should be there.
This is the 20th distinct nav-Priority+ overflow bug in the recent history (#345, #1097, #1102, #1104, #1106, #1109, #1139, #1148, #1163, #1311/#1312, …). The pattern is the same shape every time: at some narrow-ish viewport, the greedy fits() loop in public/app.js reaches a state where it either drops too much or drops nothing useful.
The screenshot's More dropdown contains ONLY the active-route pill ("Perf"). The active route may be being added to overflowQueue first AND being the only one not being protected by the high-priority floor.
Open /#/perf on staging at viewport ~1080-1100 px wide.
Observe navbar — should show brand + high-priority links + More. Instead shows only "Perf" pill.
Click More — should list missing links. Instead lists only the active-route pill.
(Width threshold may vary by viewport — operator's screenshot is ~1080px from Firefox dev tools.)
Root cause hypothesis (to verify before fixing)
In public/app.jsapplyPriorityPlus():
overflowQueue order matters. If the active-route pill (e.g. "Perf") is at position 0, the loop adds it first.
The high-priority floor (if (overflowQueue[i].dataset.priority === 'high') break;) only breaks on the FIRST hit. If the floor breaks BEFORE adding any non-high link, More is populated with… nothing extra. Then a second pass somewhere ADDS just the active pill to More.
The screenshot suggests overflow contains ONLY the active route pill, with no other links — which means inline got cleared but the floor wasn't honored.
Some new measurement noise from tonight's CSS-var addition.
Diagnose via the existing E2E test test-nav-priority-1311-e2e.js — extend to cover the /perf route at 1080px viewport.
Acceptance criteria
Reproduce locally at 1080×800 on /#/perf. Visible inline: brand + at least 3 high-priority links + More. NOT just "Perf" pill alone.
Reproduce on at least one non-active high-priority route too (e.g. /#/audio-lab — if it's still around as a high-priority link).
Active-route pill MUST always be visible inline (never overflowed to More) at any viewport.
Any link in overflow that doesn't fit MUST still be reachable via the More dropdown.
If the active route is itself NOT a high-priority link (e.g. /#/perf), the high-priority links must STILL be inline at any viewport ≥768px.
E2E regression test: test-nav-priority-1390-e2e.js (or extension of 1311) — at 1080×800 on /#/perf, assert (a) ≥3 visible links inline, (b) More dropdown contains the LINKS that overflowed (not just active route), (c) every high-priority data-priority="high" link is visible inline OR in More.
Mutation: revert the fix, assert the new E2E test fails.
Out of scope
Redesigning Priority+ as a whole (it's been touched 20 times; the algorithm is the algorithm).
Removing /perf from nav (it's a debug surface — not the navbar's fault).
Symptom
Operator screenshot of staging at ~1080px-wide viewport on
/#/perf: navbar shows ONLY the active-route pill ("Perf"). Brand + a few high-priority links should be visible inline; instead they're gone, AND clicking "More" only shows "Perf" (the active route) — not the missing links that should be there.This is the 20th distinct nav-Priority+ overflow bug in the recent history (#345, #1097, #1102, #1104, #1106, #1109, #1139, #1148, #1163, #1311/#1312, …). The pattern is the same shape every time: at some narrow-ish viewport, the greedy
fits()loop inpublic/app.jsreaches a state where it either drops too much or drops nothing useful.What's different vs prior fixes
overflowQueuefirst AND being the only one not being protected by the high-priority floor.--mc-*CSS vars in:rootthat subtly changed link rendering widths, OR fix(#1367): channels page chat-app redesign — restore prod row layout, drop analytics chip, add detail view #1376 (channel chat-app) added new mobile CSS classes that interact with the nav breakpoint media queries.Concrete repro
/#/perfon staging at viewport ~1080-1100 px wide.(Width threshold may vary by viewport — operator's screenshot is ~1080px from Firefox dev tools.)
Root cause hypothesis (to verify before fixing)
In
public/app.jsapplyPriorityPlus():overflowQueueorder matters. If the active-route pill (e.g. "Perf") is at position 0, the loop adds it first.if (overflowQueue[i].dataset.priority === 'high') break;) only breaks on the FIRST hit. If the floor breaks BEFORE adding any non-high link, More is populated with… nothing extra. Then a second pass somewhere ADDS just the active pill to More.Likely the bug is in the interplay between:
Diagnose via the existing E2E test
test-nav-priority-1311-e2e.js— extend to cover the/perfroute at 1080px viewport.Acceptance criteria
/#/perf. Visible inline: brand + at least 3 high-priority links + More. NOT just "Perf" pill alone./#/audio-lab— if it's still around as a high-priority link).test-nav-priority-1390-e2e.js(or extension of 1311) — at 1080×800 on/#/perf, assert (a) ≥3 visible links inline, (b) More dropdown contains the LINKS that overflowed (not just active route), (c) every high-prioritydata-priority="high"link is visible inline OR in More.Out of scope
Refs
public/app.js:1210-1245—applyPriorityPlus()fits/floor looppublic/style.css:1678-1729— high-priority link contract