[Feat]: Allow overlays to decide if they can be closed or not

[sorinsarca]

Code of conduct

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

Impacted component(s)

overlay

Description of the requested feature

The main problem starts here https://github.com/adobe/spectrum-web-components/blob/main/packages/overlay/src/overlay-stack.ts#L495-L501

Pressing Escape will close the overlay no matter what, and this is problematic for some modals.

Imagine that we have an upload dialog, once the user clicks the "Upload" button the process begins, and a progress bar is updated from 0% to 100% indicating the upload status. In this particular case the process is not cancellable, the user must wait until the upload is complete, otherwise the app will be (lets say) in some undefined state. Now, if the user accidentally hits Escape the dialog will close, and lots of errors will appear (because the progress bar no longer exists, but the async process tries to update it, or some other errors).

Currently the only option is to monkey-patch and set handleKeyUp method to nop, which completely disables the Escape close mode.

Mockups or screenshots

No response

Implementation notes or ideas

Maybe some isClosable property?

[Cirras]

I've run into this problem with a component nested within a modal overlay.

When focused, this nested component should completely swallow Escape keyboard events. As noted here, the overlay stack will see the Escape keyup event and close the entire modal.

The perfect solution for me would be some way to prevent the Escape keyup event from propagating to the overlay stack. My hack solution has similarly been to monkey-patch the handleKeyUp method.

[Westbrook]

There are two types of overlays that may fall into this category as we look to revisit the capability that we're offering here:

• popup=manual as outlined by OpenUI, this content is non-blocking, but can only be dismissed by direct action with the content in question or via a timer
• "page" overlay, this is synthetic to an overlay system but outlines content that acts as a new page to the application in question regardless of whether other content has been removed, it is blocking and not dismissed by user interaction unless specific UI is provided

[najikahalsema]

That second suggestion would make sense to implement for use cases like an interrupted connection during an in-progress upload, for example.