/*
 * WebinarIgnition — WordPress chrome ceiling ("WP-Deckel").
 *
 * DECISION (Tobias, 2026-09-27, variant "ceiling + clean up the exceptions"):
 *   WordPress' own cockpit is ALWAYS above everything WebinarIgnition paints — the admin bar
 *   (#wpadminbar) AND the left admin menu with its fly-out (#adminmenumain > #adminmenuwrap >
 *   #adminmenu .wp-submenu). In wp-admin and in the logged-in frontend.
 *
 * WHY A CEILING IN ONE FILE AND NOT 44 FLIPPED WI VALUES:
 *   WI lifts page-level elements above WP's chrome on purpose in a few places. The campaign
 *   header strip .editTop was the visible bug on Tobias' screenshot (it covered the left menu,
 *   its fly-out AND the admin bar). Those few places are corrected AT THEIR PLACE — .editTop is
 *   9990 now (css/webinarignition-admin.css). Every other WI value keeps its number and simply
 *   lies under this ceiling.
 *
 * THE ONE ALLOWED EXCEPTION (Tobias, 2026-09-27: "the only one that may cover the admin top bar"):
 *   the host's room teleprompter (#prompterTab in the public webinar room). It must start at
 *   y=0 on the very window edge, so it has to cover the admin bar while it is open. The exit rule
 *   at the bottom is hard-wired to the SAME condition the room CSS uses to lift the panel
 *   (inc/lp/css/webinar-modern.css ~8548-8560: `#webinarHeader:has(#prompterTab.is-open)`), so it
 *   can never fire while the prompter is closed. No JS, no second state owner.
 *
 * WHY max / max-1 AND NOT 10000000:
 *   Measured 2026-09-27 across the plugin, WI's own "always on top" numbers are wildly apart:
 *     999910      #wi-fea-fab (frontend edit pencil)
 *     999999      .wi-admin-tz-autocomplete, colour-box overlay (css/wi-admin-zero-tech.css)
 *     1000009     builder-panel overlay (css/wi-builder-panel.css)
 *     2147483000  interactive overlay + "my interests" pill (bottom anchored)
 *     2147483000  #wi-theme-setup-notice (top:0 — it COVERED the bar until it was given
 *                 `top: var(--wp-admin--admin-bar--height, 0px)`; see below)
 *     2147483646  Tawk hide pill (inc/wi-support-chat.php)
 *     99999999999 watermark (assets/webinarignition-frontend.js — the browser clamps it to max)
 *   Any ceiling below the largest of those is a ceiling on paper only. max / max-1 is the only
 *   value no WI number can beat. (The order's suggestion 2147483645 would have left the Tawk
 *   pill at 2147483646 above the bar.)
 *
 * BLOCK 2 KEEPS WORDPRESS' OWN OVERLAY LAYERS ABOVE THE CEILING:
 *   Measured on staging 2026-09-27 with the menu UNFOLDED (160px): without block 2 the left menu
 *   column painted over the WP media modal — `document.elementFromPoint()` inside the overlap
 *   returned `div#adminmenu`, and `.media-frame-content` starts at x=182, i.e. 130px of the modal
 *   were behind the menu. Before the ceiling the modal (core 160000) was above both the menu
 *   (9990) and the bar (99999). The media library modal, the drag&drop uploader, thickbox
 *   previews (WI enqueues thickbox for its image previews), the skip link and admin pointers are
 *   part of "WordPress' own cockpit" — so they stay where they were, above the chrome.
 *   Ties are resolved by DOM order: #wpadminbar / #adminmenumain are the first elements in
 *   <body>, every overlay here is appended later, so the overlay wins its tie by design.
 *
 * DELIBERATELY BELOW THIS CEILING — WI's own overlays, values NOT touched, only documented
 * (Tobias 2026-09-27: they may simply lie under the ceiling; nothing is switched off):
 *     999999      .wi-admin-tz-autocomplete, .wi-create-color-box__overlay (wi-admin-zero-tech.css)
 *     100000      .wi-optin-overlay (webinarignition-admin.css:18121), agent dock (wi-agent-admin.css)
 *     100001      agent shared (assets/wi-agent-shared.css)
 *     100100      e-mail preview / CSV report overlay (webinarignition-admin.css:17355)
 *     100101      e-mail preview backdrop (webinarignition-admin.css:17378)
 *     100100      CSV import report (wi-admin-zero-tech.css:226)
 *     100000/99999 interactive prompter composer + leave modal (.wip-*, inc/wi-prompter/wi-prompter.php)
 *     100010      relay info tooltip (webinar-modern.css:8121/8145 + cta-live JS fallback)
 *   .editTop is deliberately NOT in this list any more: it used to overtake WP on purpose and was
 *   the visible bug, so it was lowered to 9990 at its place.
 *   Consequence for WI's own full-screen overlays: they are `position: fixed; inset: 0`, so the
 *   32px chrome bar sits on their top edge. Nothing is hidden functionally today (their top bars
 *   carry only a title + close button below that edge) — if one of them ever needs to clear the
 *   bar, the WP-standard fix is a top offset (`top: var(--wp-admin--admin-bar--height, 32px)`),
 *   not a new z-index above this ceiling.
 *
 * FRONTEND SURFACES THAT RESPECT THE BAR (verified; the first two had no offset before this
 * change and were covered by the ceiling — both were fixed with it, see the commits):
 *     #wi-theme-setup-notice   -> inline `top: var(--wp-admin--admin-bar--height, 0px)`
 *                                 (inc/wi-theme-setup-notice.php); before the ceiling it sat at
 *                                 2147483000, i.e. it covered the bar.
 *     .wip-sidebar (drawer)    -> body.admin-bar + `top: var(--wp-admin--admin-bar--height, 0px)`
 *                                 in inc/wi-prompter/wi-prompter.php (its head carries the × close
 *                                 button; the drawer only exists <=560px, where the bar is 46px).
 *     .wi-tawk-hide-pill       -> body.admin-bar offset in inc/wi-support-chat.php
 *     .wi-prompter-wrap .wip-topbar -> body.admin-bar offset in inc/wi-prompter/wi-prompter.php
 *     console prompter         -> the live console calls show_admin_bar(false); no bar there.
 *
 * KNOWN, ACCEPTED EDGE CASES (noted, deliberately not built — see the review 2026-09-27):
 *     .php-error #adminmenuback is position:absolute in core, so on PHP-error admin screens the
 *     menu backdrop collapses to #adminmenumain's zero height. Rare screen, purely cosmetic.
 *     #wp-auth-check (interim login) is lifted in block 2 like WP's other overlays.
 */

/* ---------------------------------------------------------------------------------------------
 * 1) WP chrome above everything WI delivers.
 * ------------------------------------------------------------------------------------------- */

#wpadminbar {
	/* Core ships 99999 (wp-includes/css/admin-bar.css). Max, because WI's own numbers reach
	 * 2147483646 and a browser-clamped 2147483647 (see header). */
	z-index: 2147483647 !important;
}

#adminmenumain {
	/* WP 7.1.2 core has NO rule for #adminmenumain (measured in wp-admin/css/admin-menu.css:
	 * only #adminmenuback / #adminmenuwrap / #adminmenu + #adminmenu .wp-submenu are styled),
	 * so the fly-out lives inside #adminmenuwrap { position: relative; z-index: 9990 } — a
	 * stacking context of its own, which is exactly why page content with z-index > 9990 painted
	 * over the fly-out. Position + one step under max lifts the WHOLE subtree (menu, fly-out,
	 * backdrop) out of reach.
	 * position: relative is required — a z-index alone is ignored on a static element.
	 * Deliberately NOT on #adminmenuwrap: core turns that element into position absolute/fixed
	 * with z-index 100 on <=960px (auto-fold) and hides it on <=600px — forcing it there would
	 * break the folded and the mobile menu. #adminmenumain is untouched by core at every
	 * breakpoint, is a zero-height block at the same top-left origin as #wpwrap, so nothing in
	 * the admin layout moves. */
	position: relative !important;
	z-index: 2147483646 !important;
}

/* ---------------------------------------------------------------------------------------------
 * 2) WordPress' OWN overlay layers stay above the chrome — exactly as they were before.
 *    (Core values in the comments; measured regression without this block: see header.)
 * ------------------------------------------------------------------------------------------- */

.media-modal,
.uploader-window,
.wp-pointer {
	/* core: .media-modal 160000 (560000 in the customizer), .uploader-window 250000,
	 * .wp-pointer set inline by wp-pointer.js (incremented per pointer, ~1e7 and up). */
	z-index: 2147483647 !important;
}

.media-modal-backdrop,
#TB_overlay,
#TB_window,
#TB_load,
#wp-auth-check-bg {
	/* core: backdrop 159900, thickbox 100050, interim-login backdrop 1000010 — one tier under
	 * WP's own modal, as before the ceiling. */
	z-index: 2147483646 !important;
}

#wp-auth-check {
	/* Core puts the interim login dialog (1000011) ABOVE .media-modal (160000), so it gets the
	 * SAME tier as the media modal, not the backdrop tier below it (review find 2026-09-27: the
	 * first version of this block had it one tier too low). Tie resolved by DOM order — the
	 * dialog markup is printed late (wp_auth_check_html()), so it wins over the modal. */
	z-index: 2147483647 !important;
}

/* Skip links ("Skip to main content" / "Skip to toolbar", WP core) — accessibility.
 * MEASURED on staging 2026-09-27 after the ceiling: the first Tab focuses
 * `#adminmenumain > .screen-reader-shortcut`, which appears at x6 y7 (rect 185x46) and was then
 * COVERED by the admin bar — `document.elementFromPoint()` at its centre returned `a.ab-item`
 * (the bar), because a descendant of #adminmenumain can never out-rank the bar (2147483647) from
 * inside that stacking context. Before the ceiling it sat at core's 100000, i.e. above the bar.
 * Fix: keep the link's own layer inside the menu and drop it below the bar instead. `#adminmenumain`
 * starts at y=32 (bar 32px) or y=46 (<=782px), so core's own `top: -25px` put the link ON the bar.
 * `top: 7px` lands it right below the bar from 783px up AND on 601-782px. Only <=600px needs its own
 * value: core sets `html.wp-toolbar { padding-top: 0 }` there (wp-admin/css/common.css:4347), so
 * the menu container starts at y=0 and the link would land inside the 46px bar again — hence 53px
 * (= 46px bar + 7px) in the media query below. Verified at 390x844 and 1440x900.
 * The bar's own "Skip to toolbar" is a child of #wpadminbar and needs nothing: it stays inside
 * the top layer, exactly as in stock WP. */
#adminmenumain .screen-reader-shortcut:focus {
	top: 7px !important;
}

@media screen and (max-width: 600px) {
	#adminmenumain .screen-reader-shortcut:focus {
		/* 46px bar + 7px gap — the menu container sits at y=0 here (core zeroes the html padding). */
		top: 53px !important;
	}
}

/* ---------------------------------------------------------------------------------------------
 * 3) THE ONE ALLOWED EXIT — host room teleprompter, and only while it is open.
 *    PRIMARY: the body class `wi-prompter-open`, set by the ONE place that owns the state
 *    (inc/lp/partials/webinar_page/webinar-prompter-room.php, setOpen()). Works in every browser.
 *    WHY NOT :has() ALONE (Tobias 2026-09-27, reproduced): a browser without :has() support drops
 *    these rules entirely — and a browser drops the WHOLE rule if an unknown selector appears in a
 *    selector list. Measured without :has(): #wpadminbar stayed at 2147483647, the panel sat at
 *    top:0 behind it, elementFromPoint(300,5) returned the bar. That is exactly Tobias' screenshot.
 *    So the two ways live in SEPARATE rules — never in one selector list.
 * ------------------------------------------------------------------------------------------- */

body.wi-prompter-open #wpadminbar,
body.wi-prompter-open #adminmenumain {
	/* z-index: auto = back to WP's own default behaviour, so the lifted room chrome
	 * (#webinarHeader 10000000 / #prompterTab 10000001) paints over the bar and the panel really
	 * starts at y=0. Only the bar/menu lose their lift — nothing else. */
	z-index: auto !important;
}

/* Same effect as a second path, in case the class is ever missing (own rule — see the note above). */
body#webinarignition.webinar_page:not(.wi-evergreen-host-header-tools):has(#prompterTab.is-open) #wpadminbar,
body#webinarignition.webinar_page:not(.wi-evergreen-host-header-tools):has(#prompterTab.is-open) #adminmenumain {
	z-index: auto !important;
}

/* ---------------------------------------------------------------------------------------------
 * 4) Page-builder editor screens own the stacking order (2026-10-21, Michael / OptimizePress).
 *
 *    OP's live editor builds its whole UI at z-index 1000002. The ceiling above (bar = max int,
 *    menu = max-1) put WordPress ON TOP of it: the WP admin bar covered OP's toolbar and the WP
 *    menu painted over OP's canvas. That is not what the ceiling is for. The decision from
 *    2026-09-27 protects WI's OWN screens ("nothing WI paints covers WP's cockpit"); it never
 *    meant lifting WP above a third-party builder.
 *
 *    So: in a builder screen the builder decides what covers what. The ceiling stays off there,
 *    WI adds only its own shortcode panel, and if the builder hides the WP bar/menu, that is the
 *    builder's call.
 * ------------------------------------------------------------------------------------------- */

body.op-editor-active #wpadminbar,
body.op-editor-active #adminmenumain,
body.op3-builder-active #wpadminbar,
body.op3-builder-active #adminmenumain,
body.op3-editor #wpadminbar,
body.op3-editor #adminmenumain,
body.elementor-editor-active #wpadminbar,
body.elementor-editor-active #adminmenumain,
body.elementor-editor-preview #wpadminbar,
body.elementor-editor-preview #adminmenumain,
body.tcb-editor-main #wpadminbar,
body.tcb-editor-main #adminmenumain,
body.ct-builder #wpadminbar,
body.ct-builder #adminmenumain,
body.et-fb #wpadminbar,
body.et-fb #adminmenumain {
	/* auto = back to core's own values (bar 99999, menu 9990 subtree). OP's 1000002 then wins,
	 * which is exactly the intent: the builder's chrome stays on top in its own editor. */
	z-index: auto !important;
}

/* The builder iframe itself (OP designer loads the page with ?op3editor=1) has no admin chrome
 * to protect; nothing to do there, the ceiling simply finds no #wpadminbar. */