- Shipped
- September 5, 2026 at 9:21 PM UTC
- Author
- Kamo
- Commit
- 92ca0fa
Reported as the rail switching between expanded and collapsed rapidly with the pointer held still over its scrollbar, which is exactly what it did. useNavHoverPeek re-derives the peek from `elementFromPoint`, asking whether the ScrollbarLayer into a portal at <body> and painted over the rail's gutter, so the rail contains no part of it: the reconcile read "the pointer has left". That alone would only have collapsed the rail — the loop is what came next. A collapsed rail asks NavOverflowScroller for `arrows` rather than `scrollbar`, `arrows` is opted out with data-kamo-scrollbar="off", so the bar unmounts, so the rail is under the pointer again, so it peeks open, so the bar comes back. At pointermove rate. The stack under the pointer is now asked for in full, and only the scrollbar overlay layers are stepped over; the first thing beneath them decides. Stepping over ONLY those is the load-bearing part — "anything the rail is underneath counts as a hover on it" would peek the rail open behind an open dialog, so there is a test for that case sitting next to the one for this bug. Both new tests dispatch a real pointermove. The first draft of them did not, and passed with the fix disabled: advancing a frame schedules no reconcile, so they asserted that the state had not changed and would have gone green forever. Checked by disabling the fix and watching the right one fail. Also: the bar's buttons were faint grey ink at 0.55 opacity and hard to pick out on a page. Each is now a pill in the thumb's own colour carrying a white glyph, so the bar reads as one instrument rather than a grip with grey marks above and below it. Confirmed in a browser on white and on a dark rail, at full size and shrunk into a 120px panel.