- Shipped
- September 7, 2026 at 7:34 AM UTC
- Author
- Kamo
- Commit
- b6e0ae3
The application's `body` and `html` are `--background: #ffffff`, and this route is the one dark surface in it. The page element is `min-height: 100%` so it fills its scroller — but that is not everything a member can see. Three ways the white got through, none of which the page element controls: - rubber-band over-scroll at either end, which reveals what is behind the scroller entirely; - a content area shorter than the page expects, leaving a strip; - the custom scrollbar, which is painted from a portal at <body> rather than from inside the page. So the cabinet now claims the document while it is mounted, and gives it back on unmount. BOTH <html> and <body>: the root element carries a background of its own, and when it does, that is the one the browser paints on the over-scroll canvas — styling `body` alone leaves the rubber-band flash white, which is the most visible of the three. A class the stylesheet owns rather than **************** which would fight whatever set it last and leave an inline style behind; a class is reversible by construction. The effect sits above the page's early returns, so the "not switched on for you" and "could not load" curtains get the dark ground too. The cleanup is the half worth testing. Without it every other page in the application is left on a near-black body — a far worse bug than the one being fixed, visible only after navigating away, and nothing else in the suite would notice.