Alerts inside a modal can queue behind overlay

[nwhittaker]

Actual Behavior

If an open alert exists before opening a modal, any alerts opened within the modal are queued within the original alert. However the original alert is inaccessible behind the modal overlay.

Expected Behavior

Any alerts opened within the modal should probably start their own alert queue above the modal overlay. Closing the modal should restore/reveal the originally opened alert.

Reproduction Sample

https://codepen.io/nwhittaker-esri/pen/LYgRWZR

Reproduction Steps

1. View code sample and see alert queue with both alerts is obscured in background.

Reproduction Version

1.2.0

Relevant Info

No response

Regression?

No response

Priority impact

p3 - want for upcoming milestone

Impact

Our modals can have complex UIs where it's useful to use alerts to notify the user of the results of various operations within the modal.

A workaround is to programmatically close all alerts before opening a modal. It's a bit destructive, though, and not something the user might expect to happen.

Esri team

ArcGIS Field Apps

[macandcheese]

Currently Alerts are positioned fixed to the page, so the Modal / Scrim will always be blocking. We could add an alerts slot to Modal, and position the Alerts relative to Modal, although they'd likely make more sense from a layering perspective to be positioned with the Modal than "next to it" above the Scrim. We could also set them to always be on top of Scrim.

• cc @ashetland / @SkyeSeitz ?

Currently it's not possible to have grouped queues, so any Alert on the page are in the same queue. With #2835, this might be a good enhancement at the same time, do define a unique group id and associate any alerts with the same id.

[nwhittaker]

Currently Alerts are positioned fixed to the page, so the Modal / Scrim will always be blocking.

I'm not sure what you mean by blocking. Alerts inserted into a modal are positioned above the modal because they inherit the modal's stacking context: https://codepen.io/nwhittaker-esri/pen/vYVePPJ.

<calcite-modal open>
  <calcite-alert open slot="content"></calcite-alert>
</calcite-modal>

[macandcheese]

Oh, I missed the slot="content" on the Alert in Codepen, apologies, I don't think we've expected to see Alerts slotted there. We could add a designated slot for Alerts if we wanted to constrain them to the Modal visually (if we want to...), but we'd likely still need to add functionality to have two or more separate "queue groups" on a page.

[geospatialem]

Updated to an enhancement request to consider the use case. In the meantime, a z-index can be added to accommodate the use case. For instance: https://codepen.io/mac_and_cheese/pen/ZEmRGQO

[jcfranco]

I updated the above codepen to use our token CSS vars, which are available since 1.4.0.

[macandcheese]

I think an "alerts" slot in Modal like we have in Shell here makes sense. This could be useful elsewhere, maybe in Shell Panel (?) - but I do think it would require us to have a way to manage multiple Alert queues - with an Alert Group component so multiple instances / queues could exist. Or, without a wrapping Alert Group, perhaps another way like a "queue-id" property?

[mpayson]

+1. It seems like positioning alerts in modals is becoming a common pattern but it is hard to implement and position the alert correctly / reliably. Currently there are custom implementations in Map Viewer, Home app, Data Pipelines, Field Maps... so for us (Data Pipelines) it'd be a great enhancement

Would it be possible to implement in two phases, one to add the slot with a note about queuing, one to manage multiple queues?

[macandcheese]

A better workaround is use Shell where desired and then constrain the Alert within that nested Shell's alerts slot.

In this example, there is a Shell in the Modal's content slot doing this, as well as a Shell Panel containing a Shell > Panel > Alert in Shell's alerts slot: https://codepen.io/mac_and_cheese/pen/WNBNEWB?editors=1000