fix(overlays): ensure overlayIndex is greater than any existing overlay in DOM

[amanmaurya92]

Issue number: resolves #31247

---

What is the current behavior?

When a dynamically generated overlay (such as an ion-alert triggered by an ion-select with interface="alert") is opened inside an already active overlay (like an ion-modal), it can sometimes be rendered behind the active modal. This is caused by the internal lastOverlayIndex falling out of sync across different module boundaries (common in microfrontends or Angular Standalone Component architectures), causing the newer overlay to receive a lower or equal overlayIndex (and consequently a lower CSS z-index) than the active modal.

What is the new behavior?

• Modified prepareOverlay in core/src/utils/overlays.ts to actively query the DOM for all existing Ionic overlays.
• The function now calculates the true maximum overlayIndex currently present in the DOM.
• New overlays are guaranteed a mathematically higher overlayIndex by assigning the maximum between the module's lastOverlayIndex and the DOM's maxIndex + 1, ensuring the most recently presented overlay is always stacked on top.

Does this introduce a breaking change?

• Yes
• No

Other information

This fix natively relies on document.querySelectorAll to serve as a robust Single Source of Truth for the stacking order, which effectively bridges the gap in complex environments where @ionic/core modules might be duplicated or heavily code-split.

[vercel]

@amanmaurya92 is attempting to deploy a commit to the Ionic Team on Vercel.

A member of the Team first needs to authorize it.

[ShaneK]

Thanks for digging into this! I don't think it ends up changing anything in practice though. By the time this code runs, connectListeners has already set lastOverlayIndex to 1, and since we do lastOverlayIndex = overlayIndex + 1 after every assignment, the counter is always ahead of anything that's already in the DOM. So maxIndex + 1 can't win the Math.max, and you get the same numbers the old lastOverlayIndex++ was producing.

The only way the scan matters is if something else wrote an index, like a second copy of @ionic/core in the bundle. I don't see anything in #31247 that suggests that's what's happening, and there was never a reproduction attached to it. Could you get a repro together that shows an overlay actually ending up with a lower index than one that's already open? If it turns out to be a stacking context issue like #21181 was, bumping the index won't help at all.

Let me know if I'm missing something!

[amanmaurya92]

Thanks @ShaneK , that makes sense. I agree we probably need a repro before going further. I can follow up on #31247 and see if we can get one, or if you'd prefer, I can turn this into a draft or close it for now and revisit it once we have more information.