| Diskdance | |
| Mar 5 2025, 11:19 AM |
| F58772853: Recording 2025-03-11 133916.mp4 | |
| Mar 11 2025, 5:40 AM |
Feature summary (what you would like to be able to do and where):
During the development of my gadget utilizing Codex I'm meeting the requirements of "freezing" the whole dialog including disabling the close button, instead of just removing it which will cause layout shifts.
Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
To "freeze" the dialog, as said above.
Hey @Diskdance could you elaborate a bit more on what you mean by "freezing" the dialog? A demo or screenshots would be helpful if you can share them. Configuring this at the component level seems like it would be a strange system decision. You could always disable the button yourself by applying custom styling.
In this example, the dialog should be disabled as a whole when the user click "Save" and waiting for the network request to be finished. I would also like to disable the close button as well.
@Diskdance Wouldn't that mean, that a user can't escape the dialog rendering the whole page unusable in case of a network delay or drop?
It can recover from the freezing state and show user the error. I think OOUI dialogs also have a pending state which disables dialog buttons, similar to what I'm trying to achieve.
I think it's reasonable to provide an option for this if we already provide a disable prop for the primary and default actions. That said, this all feels like component config bloat. Maybe none of the disabled options should be part of the component's API, instead left to the developer using the component to implement. That is a breaking change though, so unlikely something to consider now. We'll discuss it as a team!
Design-System-Team discussed this and came to consensus that preventing a dialog from being closed (including disabling the close button) is not a pattern we want to recommend in Codex. Allowing the default actions to be disabled but not the close button was an intentional design choice.
We'd recommend using other ways to indicate a process is ongoing, like using a ProgressBar or ProgressIndicator rather than disabling forms, and always providing a way to exit the dialog. If really do want to have a close button and disable it, you could use a custom dialog header.