[Bug]: Widget "Save Snapshot" dropdown renders behind the widget's own content (z-index/stacking-context issue)

[rjonesbsink]

Which version are you running?

4.2.25

How is it installed?

Git clone on a Linux server

What page or screen were you on?

Situation Screen

What went wrong?

What went wrong

Clicking the bookmark/snapshot icon in the widget toolbar (#snapshotMenu)
opens the "Save current layout as a snapshot" dropdown — but the dropdown
panel renders behind the widget's own content instead of on top of it.
Table header text and a row from the widget underneath are visibly
bleeding through the dropdown panel. Screenshot attached.

What I expected vs. what happened

Expected: the dropdown panel appears fully on top of the widget content,
like every other Bootstrap dropdown in the app.

Actual: the widget's table content renders on top of the dropdown panel,
making the "Snapshot name..." input and part of the panel hard to read/use.

What I checked

• #snapshotMenu is a real Bootstrap dropdown trigger (app.js listens
  for show.bs.dropdown on it) — not a custom/homegrown dropdown, so this
  isn't a "missing dropdown wiring" issue.
• .snapshot-dropdown (assets/css/widgets.css) has no z-index set at
  all — just max-height and overflow-y: auto.
• Grepped the whole stylesheet for z-index: there's exactly one
  declaration in the file, z-index: 10, on the widget Action Bar
  (the icon row on incident/responder/facility widget headers).

My guess (not fully confirmed without live DevTools inspection) is a CSS
stacking-context issue rather than a simple z-index-value comparison —
if the dropdown's ancestor widget container establishes its own stacking
context (e.g. via transform, which the drag/resize grid layout likely
uses for widget positioning), the dropdown's own z-index only applies
within that trapped context, letting a sibling widget's Action Bar (or
similar) visually win despite the numbers suggesting otherwise.

Possible Fix - pending your input.

Give .snapshot-dropdown (or more specifically, the actual
.dropdown-menu it decorates) an explicit z-index high enough to clear
whatever's currently winning — and if a stacking context on an ancestor
widget container turns out to be the real cause, that same fix would
likely need to travel with the dropdown itself (e.g. z-index: 1055 or
similar, matching/exceeding Bootstrap's own dropdown z-index tokens)
rather than just bumping the widget Action Bar's z-index: 10 down,
since other things may depend on that value.

What steps lead to it?

No response

Screenshot (optional)

What device / browser?

windows laptop - chrome - safari - edge

[ejosterberg]

Fixed. Your read on this was right, and the investigation you'd already done (confirming it's a real Bootstrap dropdown, checking the stylesheet for existing z-index rules) meant there wasn't much left to diagnose.

Gave .snapshot-dropdown an explicit z-index: 1055 — matching a convention that already exists elsewhere in this codebase for the identical problem: searchable-select.css and radio-widget.css both use 1055 for elements that need to clear GridStack widget content (just under Bootstrap's own modal tier, so it beats ordinary page/widget content without competing with an actual modal). Confirmed the class is applied directly to the real .dropdown-menu element in index.php, so this is a one-line, targeted fix rather than a guess.

New tests/test_gh110_snapshot_dropdown_zindex.php pins the z-index to that established convention specifically (not just "any positive number"), so a future edit that drifts to some other value gets caught. Verified against a reverted copy of the fix that it correctly fails without the z-index present.

Fixed in fa6a7a2 (same commit as GH#109, landed together), deployed to both training.ticketscad.com and bloomington-auxcomm.