Missing attribute changed steps for dialog can cause assertions to be hit

[lukewarlow]

What is the issue with the HTML Standard?

Currently showModal() and show() on a dialog, assert that the dialog isn't in document's open dialogs list.

However, it turns out this isn't always true.

For example if you do:
dialog.showModal(); // Adds the dialog to the open dialogs list
dialog.removeAttribute('open'); // Dialog is now in a strange state
dialog.showModal(); // Assertion fails because the dialog is already in the open dialogs list

The spec needs attribute changed steps for dialog open attribute being removed and needs to remove the dialog from the list.

[lukewarlow]

Related to #5802 but a more scoped and required fix for the spec.

[domenic]

I don't understand why the correct fix here is to implement some subset of #5802 instead of removing the broken assert.

[lukewarlow]

For the close watcher aspect it would actually be broken behaviour right now I think. The original close watcher would never be removed from the list so I'm assuming events would fire twice or it would lead to null reference or something.

This also is what chrome implements so I thought it's generally best for the spec to match implementations.

[lukewarlow]

Also removing the assertions doesn't prevent bugs occurring. open dialogs list is a list not an ordered set, which means it can have duplicate entries. I don't know if doing remove(this) only removes the last one or all matching entries but I can potentially see that causing issues too.

[lukewarlow]

cc @mfreed7 (and @keithamus because I know you're implementing in Firefox)

[keithamus]

Yeah it seems the change is observable. We could change the set the dialog close watcher steps to tear down the existing close watcher, if it exists, but that seems a little awkward. I wonder if this allows some level of circumvention of the close watcher anti abuse mechanisms, also?

[domenic]

Alright, thanks for explaining. It sounds like we have a few options:

• Revert Add dialog light dismiss behavior #10737 entirely. Sad, not fun.
• Patch up the spec by removing the broken assert and fixing any other issues that are caused by the new setup. Complicated, unclear.
• The minimal change in Add attribute changed steps to dialog element #10954.
• The more maximal fix in Close dialog elements when the open attribute is removed #10124, and/or some other more maximal fix for Dialog should be better-behaved on misuse, probably #5802.

Assuming other implementers are OK with it, I'm happy with trying to move forward and applying one of the fixes. I'd appreciate a summary of the delta between #10954 and #10124 / the proposals in #5802 though, to know what the future evolution might look like.

[lukewarlow]

I'll try my best to summarise the differences not wishing to speak for @josepharhar (feel free to correct me if I'm wrong).

#10954 is a minimal set of changes needed to satisfy the spec assertions as written (with the addition of an extra one for clarity), and to match the actual implementation within Chromium (again @mfreed7 correct me if I'm wrong on that).

In summary it adds a new attribute changed step for the dialog element such that if the open attribute is removed, the dialog is removed from the document's list of open dialogs, preventing assertions in showModal/show being hit. It also destroys and nullifies dialog's close watcher, asserting this within 'setup the dialog close watcher'. While definitely a normative change it's designed to spell out the necessary changes for the spec to be in a good state.

#10124 is a more maximal approach to the wider problem of the open attribute, it does new normative changes which solve wider UX (but not spec) issues such as modal dialogs still blocking the document. It does this by invoking the full close algorithm of the dialog, which ensures full cleanup of state. So it's a superset of my proposed change. This requires more thought on changes related to focusing which is I believe the hold up on it.

Side Note: I'm fully supportive of the direction of #10124 and I think it should be the eventual end state of the spec.

I don't think reverting the PR is the best approach, despite contentions around process I believe there is overall support of at least two implementors for the overall gist of the addition and it's largely just the exact specifics that need cleaning up. I also don't believe we would have necessarily found all these issues before merging even if it had stayed unmerged for longer.

I also don't think patching up the spec by removing assertions etc is the correct approach either. I believe there could be observable differences between cleaning up upon calling show/showModal and cleaning up upon removal of the open attribute.

Specs should generally match implementations and that is what my PR proposes.

[keithamus]

to know what the future evolution might look like.

#10954 is/can effectively be a subset; that is to say I believe it is entirely plausible for us to merge #10954 and follow up with #10124. I believe #10954 (or at least something like it) is necessary, and #10124 just adds extra steps that aren't in conflict.

[mfreed7]

Thanks for highlighting this issue! And I roughly/completely agree with the above comments. #10124 is the best eventual state, #10954 is a great (and perhaps less risky?) intermediate step, and we should attempt to land both. Both PRs make the open attribute behavior incrementally better. I suppose we could try to just jump directly to #10124, but that'd require some compat work or an attempt to ship it in a browser. I'm willing to try to do that in Chromium, if it helps the effort, and folks are onboard with that plan.

open dialogs list is a list not an ordered set, which means it can have duplicate entries.

This is a very interesting point. In Chromium, it's actually an ordered set, but also with the same assertions that the spec has, to make sure we're not using it as a set. Kind of belt and suspenders, but I wonder if the spec should make it an ordered set? Given the assertions, it shouldn't be observable.

[domenic]

Thanks all; that was very helpful. With my editor hat on, I'm convinced that #10954 first is the way to go. I hope someone can follow up with the rest of the #10124 stuff in due time.

We still need to formally confirm multi-implementer interest beyond Chromium. If @lukewarlow can speak for WebKit and/or @keithamus can speak for Gecko in that regard, that's excellent, but I'll defer that judgement to you two.

[lukewarlow]

We still need to formally confirm multi-implementer interest beyond Chromium. If @lukewarlow can speak for WebKit and/or @keithamus can speak for Gecko in that regard, that's excellent, but I'll defer that judgement to you two.

I'm unfamiliar with whatwg procedure on that point but I don't believe I can formally speak for WebKit. Cc @annevk

Having said that they've recently indicated that they will mark the wider feature as positive.