mirror of https://github.com/zulip/zulip.git
828867c733
Previously, our modal system prevented opening a modal when one was already open. It appears this was implemented to work around the fact that we're using Micromodal selectors to determine if a modal is open (and those don't update until after an animation frame). We'd like to support opening the full user profile and manage user modals while read receipts is open. While we could work around this in that place, it feels like one needs a lot of documentation in order to add a setTimeout in those code paths. So we instead make open_modal support this, with a guard to prevent infinite recursion in case of future bugs. Note that dialog_widget was already closing modals before opening the next one, so this is a behavior change only for our 3 modals that do not use dialog_widget. (I'm not sure why the `dialog_widget` modals did not already require a delay, but likely there's some CSS difference). We likely will want to redo this to instead use a better state tracking system. See https://chat.zulip.org/#narrow/stream/49-development-help/topic/close.20and.20open.20another.20modal.20immediately for discussion. |
||
|---|---|---|
| .. | ||
| assets | ||
| audio/notification_sounds | ||
| generated | ||
| html | ||
| images | ||
| js | ||
| shared | ||
| styles | ||
| templates | ||
| third | ||
| .gitignore | ||