- Shipped
- September 6, 2026 at 9:56 PM UTC
- Author
- Kamo
- Commit
- 4ea142b
The admin bar's dropdowns were painting under the App Shelf's scrollbar, and lowering the shelf's z-index last time did not help — because the number was never the problem. The launchpad's content wrapper is `position: relative` with `zIndex: 1`, which makes it a STACKING CONTEXT. Everything inside is then capped at level 1 of the root context: a dropdown asking for 40 is really painting at 1. ScrollbarOverlay portals its bars to the body and gives them their scroller's nearest z-indexed ancestor PLUS ONE — 2 for a resting pane — so every bar on this page drew over every dropdown on it, whatever numbers either side chose. overlayGeometry says as much in its own doc: "a scroller in the page shell sits under an ancestor at z-index 1 and gets 2". The wrapper does not need to be a stacking context. The Backdrop is z-index -1, and a positioned element with no z-index already paints above that. Measured in a browser against a faithful copy of the page's structure, with the real ScrollbarLayer mounted: with the context, the bar wins the overlap; without it, the dropdown does — shelf open (pane 12, bar 13, dropdown 40) and shut (bar 1) — and the backdrop stays behind the content. Two notes for the next person. My first probe of this omitted the wrapper, so it "passed" against the bug. And elementFromPoint is not a paint-order test here: the overlay container is pointer-events none, so the hit test skips it and names the wrong winner unless you force pointer-events on first.