Support disabling CloseWatcher integration in <dialog>

[lucacasonato]

What problem are you trying to solve?

Right now one can not really use <dialog> to grab the users attention until they complete some action. This is because <dialog> always lets the user close it through native UI, even when the developer explicitly does not want to allow this (ie when using cancel events). This is done in HTML to prevent malicious sites from blocking the Android back button. This is good!

However, there are genuine use cases for unclosable <dialog>:

• a upload progress modal that prevents the user from continuing until the upload is done
• a "Please accept our terms of service" modal after signing in that should not be dismissable, because a user must accept TOS before using the service
• a required action before progress can be made, such as a "Please enter your name" modal before you can join a video call / online game

As such, it would be great if we had a way to open an unclosable dialog. This dialog would not have any CloseWatcher integration at all: pressing escape or the Android back button would completely bypass the dialog and instead do their default behaviour (like navigate back in the navigation history).

What solutions exist today?

No solutions using the native <dialog> element. One would have to reimplement the behaviour.

A solution that will probably be gone soon: https://issues.chromium.org/issues/363225474

How would you solve it?

dialog.showModal({ closeBehaviour: "manual" });

Anything else?

No response

[lucacasonato]

I opened a tenative PR - it should be trivial by everyone that implements CloseWatcher to implement: #10593

[domenic]

I think this has large overlap with the discussions in #9373 (which is unfortunately pretty long). That ended up in #10157 which was recently closed, but I think @mfreed7 still wants to pursue it.

The big difference is that proposes a new HTML attribute as opposed to your new option to showModal(). (That makes it extra hard as you have to deal with attribute addition/removal/mutation while the dialog is open.) And that has more options, although I like the idea of just starting with two.

[lucacasonato]

Oh I like that proposal a lot - that interacts much better with a future where one can open dialogs declaratively from HTML, like we support for popover now.

If that @mfreed7 is going to work on that issue, then I'm happy to have that be the solution for this problem :)

Maybe we can simplify that proposal by initially only doing closedby="none" and `closedby="closerequest" as a first pass? That allows us to do the backdrop click close machinery as a follow up.

(Also I think this should be called autocloseby, because closeby="none" is backwards with the fact that you can still call dialog.close().)

[lukewarlow]

That ended up in #10157 which was recently closed, but I think @mfreed7 still wants to pursue it.

Yeah I recently closed it because I don't really have the time to really work out the spec details of it but I think what's there and from our discussions is pretty close.

Maybe we can simplify that proposal by initially only doing closedby="none" and `closedby="closerequest" as a first pass? That allows us to do the backdrop click close machinery as a follow up.

Fwiw the backdrop click is the relatively easy part, we already have the machinery from popover. The difficulty is actually the none option and how to handle it dynamically changing.

TLDR: What do you do with the close watcher stack if you go from none -> closerequest, same with the other way around? I think we need a new activation flag on close watchers but getting the spec handling right for that is tricky due to stuff like the stacking behaviour.

One option we do have is to just not support dynamic update, either by closing the dialog or by leaving it open and the change having no immediate effect. But I think @domenic has a preference for handling this properly?