- Shipped
- September 6, 2026 at 12:59 AM UTC
- Author
- Kamo
- Commit
- 9b20546
The last fix reserved the scrollbar's space but it still could not be seen, and the reason was not the scrollbar. BackgroundStage is `position: fixed` with the pane as its containing block, and because that containing block sits ABOVE the scroller, the browser lifts it out of the scroller's scrolled contents — which is exactly what stopped it drifting up the page, and also what stops the rule that a scroll container paints its bar above its own content from protecting that bar. It is `inset: 0`, blurred 3px, and overscaled 1.03 to hide the soft edge that blur leaves, so it covers the pane's full width and a further twenty pixels besides. The scrollbar was being drawn underneath it. `inset: 0` resolves against the padding box and `overflow: hidden` clips to the padding box, so a BORDER is the one part of this pane the artwork provably cannot reach. The pane grows a right border the width of the strip, the scroller overhangs into it by the same amount, and the bar lands there. The content area is unchanged — the width added is exactly what the scrollbar occupies — and the border is painted in the scrollbar's own track colour, so the four pixels Chrome leaves over when it draws a thin bar in a fourteen pixel strip show no seam. Measured at the pane's right edge, the fourteen pixels inside it: rgb(31,78,121) before, the lender's brand blue bleeding across the gutter; rgb(241,239,234) now, the track's own colour. That is the whole of the bug in two samples. Still not seen by eye — this machine has no display and headless Chrome does not paint scrollbars into screenshots at all. What is confirmed is that the strip now belongs to the scrollbar rather than to the artwork, that the space stays reserved, that the background still moves 0px while the pane scrolls 350, and that the eleven-viewport sweep is clean with the rail at exactly the pane's height.