[Bug]: interaction="manual" overlay — sp-opened never dispatches when interaction="modal" overlay is active, causing app freeze

[SnehaKandpal157]

Code of conduct

• I agree to follow this project's code of conduct.

Impacted component(s)

@spectrum-web-components/overlay

Library version

@spectrum-web-components/overlay: 1.9.0

Expected behavior

sp-opened fires on bgTrigger within ~50ms, consistent with normal manual overlay behaviour.

Actual behavior

When an interaction="modal" overlay is open, calling Overlay.open(trigger, "manual", content, opts) on a background element causes sp-opened to never dispatch on the trigger. The overlay gets permanently stuck in state="opening".

In applications that await sp-opened to resolve an open-state promise, this causes a complete and unrecoverable app freeze — Lit's update cycle hangs indefinitely and the page must be reloaded.

sp-opened never fires. The overlay is permanently stuck in state="opening". No error is surfaced to the caller.

Screenshots

No response

What browsers are you seeing the problem in?

Chrome

How can we reproduce this issue?

1. Open an interaction="modal" overlay (e.g. via Overlay.open(trigger, "modal", content, opts)) and wait for sp-opened to fire on its trigger.
2. While that modal overlay is still open, call Overlay.open(bgTrigger, "manual", content, opts) on a background element
3. Listen for sp-opened on bgTrigger

Sample code or abstract reproduction which illustrates the problem

showModal() — called internally by SWC when opening a type="modal" overlay — makes all background elements natively inert per the HTML spec. When SWC subsequently tries to open the manual overlay, it calls showPopover() on an element that is now in the inert subtree. The browser throws NotSupportedError. This throw is unhandled and aborts the open sequence before makeTransition() runs, so sp-opened is never dispatched.

Overlay.open(trigger, "manual", ...)
→ managePopoverOpen()
→ ensureOnDOM()
→ shouldShowPopover()
→ this.dialogEl.showPopover() // ← throws NotSupportedError, no try/catch
→ ensureOnDOM() aborts
→ makeTransition() never called
→ sp-opened never dispatched
We believe the fix belongs in OverlayPopover.shouldShowPopover() — wrapping showPopover() with a try/catch and setting this.open = false on NotSupportedError so sp-closed fires and callers can recover gracefully:

try {
    this.dialogEl.showPopover();
    this.managePosition();
} catch (err) {
    if (err instanceof DOMException && err.name === 'NotSupportedError') {
        this.open = false; // triggers sp-closed so callers can recover
        return;
    }
    throw err;
}

Severity

None

Logs taken while reproducing problem

No response

Would you like to track this issue in Jira?

• Yes, please tell me the ticket number!

[najikahalsema]

@magento export issue to Jira project SWC as Bug

[github-jira-sync-bot]

✅ Jira issue SWC-2276 is successfully created for this GitHub issue.

[Rajdeepc]

Hi @SnehaKandpal157 Can you help me understand your DOM setup first before we call this a bug on our side.
Also is there a native <dialog> using .showModal(), an inert attribute, or a display: none/content-visibility: hidden ancestor in the DOM tree above the manual overlay's trigger?
SWC removed its internal showModal() before your v1.9.0, so the inertness must be introduced by the surrounding application code and not caused by SWC. But as you have explained NotSupportedError is real, we should handle this gracefully.
You can start from here