README.md

@@ -379,9 +379,6 @@ Then put it behind your existing reverse proxy like everything else
 - [x] Fixed the music bar's queue popup — a missing `position` broke
       the desktop layout when opened and left it unclosable on mobile
       (its own close button was reachable now) — see docs/architecture.md
-- [x] Fixed library tile buttons rendering on top of the sticky header
-      while scrolling — an equal z-index tie that a scrolling tile won
-      — see docs/architecture.md
 - [ ] Try a full party end-to-end with two real accounts (still the main gap)
 - [ ] Try casting to a real Chromecast (only the SDK's own bootstrap is
       confirmed here — no real device/session)

client/src/alphaIndex.css

@@ -8,11 +8,7 @@
   grid-column: 1 / -1;
   position: sticky;
   top: var(--section-sticky-top, 0px);
-  /* Same z-index: 3 as views/library/Library.css's own .libraryHeader,
+  z-index: 2;
-     and for the identical reason: tiles.css's .tileOverlay is z-index:
-     2, and a tie there breaks toward whichever renders later in the
-     DOM - a tile, always after this heading. */
-  z-index: 3;
   background: var(--bg);
   color: var(--accent-bright);
   font-size: 13px;

client/src/views/library/Library.css

@@ -8,18 +8,7 @@
 .libraryHeader {
   position: sticky;
   top: 0;
-  /* Above 2, not just tiles.css's own .searchBar precedent: a tile's
+  z-index: 2;
-     .tileOverlay action buttons are ALSO z-index: 2, and (unlike the
-     slim .searchBar this header replaced) this header is tall enough
-     that a scrolling tile's own overlay - always-visible on touch, see
-     tiles.css's (hover: none) block - reaches it well before it's fully
-     scrolled past. Equal z-index ties break on paint order, and a tile
-     (inside #grid, after this header in the DOM) wins that tie -
-     reported directly as buttons rendering over the header while
-     scrolling. z-index: 3 matches shell/Shell.css's own .mobileTopBar,
-     the other sticky header this one already has to stack correctly
-     under on mobile. */
-  z-index: 3;
   background: var(--bg);
   padding-top: 4px;
 }

docs/architecture.md

@@ -4160,42 +4160,6 @@ itself (not something on top of it), and closing the queue correctly
 returned to the still-open now-playing panel rather than closing
 everything.
 
-## Library tile buttons rendering on top of the sticky header
-
-Reported directly: scrolling a library, a tile's own action buttons
-("Lancer une watch party" / "Voir sur Emby") would briefly render
-*above* the sticky title+search header instead of scrolling behind it.
-
-Both `.libraryHeader` and the alphabet index's `.letterHeading` were
-`z-index: 2` - copied from `tiles.css`'s own pre-existing `.searchBar`,
-sticky at that same value long before either of them existed. What
-that copy missed: a tile's own `.tileOverlay` (its hover-revealed
-action buttons - always-visible rather than hover-revealed on a touch
-device, see `tiles.css`'s `(hover: none)` block) is *also* `z-index: 2`.
-Equal z-index is a tie, and a tie breaks toward whichever renders later
-in the DOM - a tile, inside `#grid`, always after the header. The
-original slim `.searchBar` never showed this in practice (a single
-input has little vertical range to actually overlap a scrolling tile
-during the transition); wrapping it into the much taller
-`.libraryHeader` gave a scrolling tile far more room to pass directly
-underneath before fully clearing it, is what actually surfaced it.
-
-Fixed by raising `.libraryHeader` and `.letterHeading` to `z-index: 3`
-- comfortably clear of `.tileOverlay`'s 2, and matching
-`shell/Shell.css`'s own `.mobileTopBar` (the other sticky header
-`.libraryHeader` already has to stack correctly under on mobile).
-
-Verified: full `typecheck`/`build` (client only). Confirmed as a real
-regression, not just reasoned about - real compiled CSS loaded into a
-page reproducing `.libraryHeader` + a real `.grid` of tiles (their
-`.tileOverlay` forced visible, simulating a touch device), scrolled so
-a tile genuinely overlapped the header's own rect, then
-`elementsFromPoint` read the actual paint order at that point: with
-the header's z-index forced back to the old `2`, `.tileOverlay` topped
-the stack exactly as reported; restored to `3`, the header (and the
-search input inside it) topped it instead, `.tileOverlay` three layers
-down, unreachable.
-
 ## Known limitations
 
 - Playback always goes through `hls.js` against whatever Emby's