System-modal dialogs block access to useful stuff - make them window-modal instead
System-modal dialogs can cause issues, particularly when they involve text input: while the modal dialog is in place, the user cannot access the input source menu, the accessibility menu, or apps used to store passwords. This causes issues if you want to change the keyboard layout, activate an accessibility feature, or look up a password.
There are two situations when I think we do want dialogs to be system-modal:
- When the action is about a significant system-wide change. Here, system-modality means that the user doesn't lose the dialog, and it elevates the seriousness and authority of the dialog. A good example of this is the end session dialogs.
- When the dialog was triggered from the shell. This is mostly because we don't want free-floating shell dialogs.
Outside of these cases, I don't think that the dialog needs to block the whole session. In these cases, it would be sufficient to make the dialog window-modal rather than system-modal.
Dialogs that could be treated in this way:
- Authentication dialogs (polkit, etc)
- Portal request dialogs (access camera, microphone, location services, etc)
- Inhibit shortcuts
- Network authentication (if it's triggered from an app)
It's worth pointing out that, if we went ahead with this change, there would still be cases where people would encounter system-modal dialogs with text entries:
- Run dialogs
- Volume unlock for removable devices
- Network authentication when it is triggered from the shell (such as from the Wi-Fi neworks dialog, or the VPN sub-menu)
- Keyring unlock