.sm_megamenu_wrapper_menu_full {
    z-index: 800 !important;
}

.sm_megamenu_wrapper_horizontal_menu .sm_megamenu_menu .sm_megamenu_dropdown_1column,
.sm_megamenu_wrapper_horizontal_menu .sm_megamenu_menu .sm_megamenu_dropdown_2columns,
.sm_megamenu_wrapper_horizontal_menu .sm_megamenu_menu .sm_megamenu_dropdown_3columns,
.sm_megamenu_wrapper_horizontal_menu .sm_megamenu_menu .sm_megamenu_dropdown_4columns,
.sm_megamenu_wrapper_horizontal_menu .sm_megamenu_menu .sm_megamenu_dropdown_5columns,
.sm_megamenu_wrapper_horizontal_menu .sm_megamenu_menu .sm_megamenu_dropdown_6columns,
.sm_megamenu_wrapper_horizontal_menu .sm_megamenu_menu .sm_megamenu_dropdown_fullwidth {
    z-index: 800 !important;
}

/* Not mega-menu selectors: .modal-popup.smcqp-confirm (Sm_CartQuickPro's
   remove-item/compare/wishlist confirm dialogs) and .smcqp-modal-popup
   (its add-to-cart/removal success notices) both need to render above the
   header. The theme already had a partial fix for smcqp-modal-popup only,
   without !important. Filed here rather than a new module since this is
   the same "header/shared-UI element outranks a modal" bug class this
   module already exists to patch.

   .modals-overlay is a SHARED singleton backdrop reused by every modal on
   the site (login popup, newsletter popup, etc. at the default z-index
   ~899/900) - Magento's modal.js re-assigns its z-index via inline style
   every time ANY modal opens, dynamically, independent of this CSS, using
   what appears to be a running/shared counter rather than a value scoped
   to just the current modal. Pinning only the dialog (without also
   pinning the overlay) left the overlay free to land ABOVE the dialog
   whenever a modal had recently opened before it in the same session -
   confirmed happening on TWO separate modals in the same real user flow:
   the remove-confirm dialog (right after dismissing the add-to-cart
   success modal) and the post-removal "Item was removed successfully"
   notice (right after the remove-confirm's OK) - both landed with the
   overlay one z-index level above the dialog, silently blocking every
   click on the dialog's buttons with no console error, since nothing
   ever threw. A tied z-index isn't sufficient either: the overlay and
   dialog are siblings under the same .modals-wrapper container, and the
   overlay is consistently the later sibling, so on a tie it still wins.
   Because this reproduced on a second, different modal class after the
   first fix went out, this rule intentionally covers BOTH custom modal
   classes together rather than being re-patched one at a time.

   Fix: force the overlay strictly below both dialog classes, scoped via
   :has() to only when one of THEM is open, so other modals' normal
   overlay stacking (~899/900) is untouched. Reproduced and verified
   against production via a local headless-browser test harness for the
   full add -> success -> remove-confirm -> OK -> success chain before
   deploying (2026-08-18). */
.modals-wrapper:has(.modal-popup.smcqp-confirm._show) .modals-overlay,
.modals-wrapper:has(.modal-popup.smcqp-modal-popup._show) .modals-overlay {
    z-index: 20999 !important;
}

.modal-popup.smcqp-confirm,
.modal-popup.smcqp-modal-popup {
    z-index: 21000 !important;
}