fix(modal): keep body-portaled dropdowns above their tool modal at any stack depth (#4720) (#4724)

* fix(memory): keep the Brain memory item menu above the modal at any stack depth The memory item "⋮" dropdown is portaled to <body> with a hardcoded z-index of 10001. Tool modals, however, get a monotonically increasing z-index from modalManager's bring-to-front counter (_modalTopZ), which climbs unbounded as modals are opened/restored over a session. Once that counter passes 10001, the Brain modal stacks above the body-portaled dropdown, so the menu renders behind the panel — visible only where it spills past the modal's edge (#4720). Derive the dropdown's z-index from the owning modal's current z-index (+1), keeping 10001 as a floor for the common low-counter case, so the menu always sits just above its modal however high the counter has climbed. Verified with document.elementFromPoint at the dropdown's location: with a high modal z-index the old build returns the modal at every sampled point (menu behind); the fixed build returns the dropdown (menu on top). The default low-counter case is unchanged (z stays 10001). * refactor(modal): route body-portaled dropdowns through a shared topPortalZ() helper The hardcoded z-index:10001 the Brain memory menu used (#4720) is the same literal shared by ~16 body-portaled dropdowns across calendar, cookbook, cookbookServe, documentLibrary, emailLibrary, gallery, notes, emojiPicker and memory — each renders behind its owning tool modal once modalManager's bring-to-front counter climbs past the literal over a long session. Promote the per-dropdown fix into a single topPortalZ() helper in toolWindowZOrder.js — the existing source of truth for tool-window z, already imported by modalManager's _bringToFront and notes.js — returning max(topToolWindowZ(), dock-chip floor) + 1, so a portaled dropdown always sits just above the live tool-window stack however high the counter has climbed. Route all 16 sites through it. The slashCommands tour tooltips and the cookbookServe VRAM dialog are intentionally left out (neither is a modal-owned portaled dropdown). Add tests/test_portal_dropdown_z_js.py covering the helper, including the #4720 scenario (modal counter at 99999 -> dropdown at 100000). Existing test_notes_z_order_js.py stays green.
2026-06-23 21:25:33 -04:00 · 2026-06-23 16:24:31 +08:00
parent 7e5db9a3c6
commit fef08ed114
11 changed files with 137 additions and 16 deletions
@@ -27,3 +27,20 @@ export function nextToolWindowZ(options = {}) {
  if (Number.isFinite(currentZ) && currentZ > top) return currentZ;
  return top + 1;
 }
+
+// Dock chips pinned by the minimized-dock drag interactions reach z 10030
+// (free-drag) / 10020 (mobile rest) — see modalManager.js. A body-portaled
+// dropdown has to clear those too, not just the open tool-window stack, so this
+// floor keeps it above a chip even when no modal is currently raised.
+const DOCK_OVERLAY_FLOOR = 10030;
+
+// The z a body-portaled dropdown/menu needs so it always sits just above every
+// open tool window (and the dock chips) right now. Tool modals get a
+// monotonically increasing z from the bring-to-front counter (modalManager),
+// which climbs unbounded over a long session — so the hardcoded `z-index: 10001`
+// these dropdowns historically used eventually rendered them BEHIND their own
+// modal (#4720). Derive the value from the live stack instead, sharing the same
+// single source of truth as nextToolWindowZ().
+export function topPortalZ(options = {}) {
+  return Math.max(topToolWindowZ(options), DOCK_OVERLAY_FLOOR) + 1;
+}