Update dialog to minimally handle open attribute mutations #10954

lukewarlow · 2025-01-27T20:12:53Z

Update dialog to minimally handle open attribute mutations

We define two new algorithms for dialog:

Dialog cleanup steps which:
1. Removes dialog from the document's open dialogs list
2. Destroys and nullifies dialog's close watcher
Dialog setup steps which:
1. Adds dialog to the document's open dialogs list.
2. Creates the dialog's close watcher.

We also define attribute change steps and HTML element insertion steps for the dialog element.

We call dialog cleanup steps when:

a) An open dialog is removed from the document
b) A connected dialog has its open attribute removed

We call dialog setup steps when:

a) An open dialog is inserted into the document
b) A connected dialog has an open attribute added to it

This fixes spec issues that can lead to assertions being hit but also incorrect behaviour. This also fixes closedby not working as expected for initially open dialogs.

Fixes #10953 and #10982

At least two implementers are interested (and none opposed):
- Chromium - Already implements this.
- …
Tests are written and can be reviewed and commented upon at:
- This behaviour is already enforced by multiple Web platform tests. e.g. https://wpt.live/html/semantics/interactive-elements/the-dialog-element/dialog-remove-open-attr-crash.html
- Added better test coverage for requestClose and initially open dialogs: Add requestClose() subtests for initially open dialog web-platform-tests/wpt#50432
- https://wpt.live/html/semantics/interactive-elements/the-dialog-element/dialog-closedby-start-open.html - Added by Chromium change
- Added a new test that doesn't rely on Assertions: Add test for dialog attribute changed steps web-platform-tests/wpt#50393
Implementation bugs are filed:
- Chromium: N/A
- Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1936940 (meta bug)
- WebKit: https://bugs.webkit.org/show_bug.cgi?id=284592 (meta bug)
Corresponding HTML AAM & ARIA in HTML issues & PRs: n/A
[ x] MDN issue is filed: N/A
The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

/interactive-elements.html ( diff )

domenic · 2025-01-28T06:46:44Z

This behaviour is already enforced by multiple Web platform tests. e.g. https://wpt.live/html/semantics/interactive-elements/the-dialog-element/dialog-remove-open-attr-crash.html

This test would also pass if we removed the assert, i.e. fixed the regression introduced recently.

Marking "do not merge yet" until we get more clarity in #10953 as to what the right path forward is.

domenic

Removing "do not merge yet" as I'm convinced by the arguments in #10953, but of course we still need to check all the boxes to merge.

For the tests box, could you point to more tests that enforce this behavior that aren't crash tests? Since assertions are actually comments; they don't cause crashes.

source

lukewarlow · 2025-01-30T20:07:12Z

I've opened web-platform-tests/wpt#50393 which fails in a browser which follows the current spec:

I tested by locally modifiying chrome to use an ordered list for the open dialogs list, and removed the attribute changed set. In that build both the escape case and the click outside case result in the dialog being closed when it shouldn't be.

lukewarlow · 2025-02-01T19:10:46Z

Have rebased with Keith's changes hopefully it's where its needed as of the new model.

I think this just needs Implementer interest. I believe whatwg needs someone appointed by the projects to provide a position, so me for WebKit and Keith for Firefox wouldn't be enough. (Cc @smaug---- and @annevk )

lukewarlow · 2025-02-02T22:35:35Z

Per https://issues.chromium.org/issues/384549097 I've changed the new assertion within set the dialog close watcher to be an early return as it's possible that this scenario happens in legitimate cases (see the issue for more detail).

source

mfreed7 · 2025-02-07T19:40:44Z

FYI, see comments at #10953 (comment) and after.

lukewarlow · 2025-02-12T12:11:09Z

source

@@ -62178,6 +62210,9 @@ interface <dfn interface>HTMLDialogElement</dfn> : <span>HTMLElement</span> {
  element <var>dialog</var>:</p>

  <ol>
+   <li><p>If <span>dialog</span>'s <span data-x="dialog-close-watcher">close watcher</span> is not


Need to work out if we actually still need this. It's in Chromium atm but based on other changes may no longer be needed (instead can be replaced with an assert)

lukewarlow · 2025-02-12T12:33:17Z

This has been updated to account for changes per discussions at whatnot, above and in the Chromium CL.

TLDR we now handle adding the open attribute and removing it slightly more gracefully. This should fix various assertions being hit aswell as requestClose being broken.

I've left open dialogs list as a list in spec despite it being a set in Chromium, the various assertions should ensure this isn't an observable difference (happy to make that change if it's desired?).

lukewarlow · 2025-02-12T12:35:21Z

Pending approval from a second implementor this should be ready to go (aside from editorial remarks).

Though it would be good for @mfreed7 to check my homework.

mfreed7 · 2025-02-13T16:58:15Z

Pending approval from a second implementor this should be ready to go (aside from editorial remarks).

Though it would be good for @mfreed7 to check my homework.

Thanks for updating this!

So as I'm working on the Chromium changes, I've got another CL going that (I think) better handles the additional case that a <dialog open> is removed and inserted into the document. The general idea would be to remove the dialog from the open dialogs list and kill its closewatcher when the dialog is removed from the doc, and vice versa. I'm still working on it, but I do think there might still be some cases that this PR doesn't cover. Perhaps let me get that CL into working shape and then I can come back here and reconcile it with this PR?

lukewarlow · 2025-02-13T17:02:27Z

So as I'm working on the Chromium changes, I've got another CL going that (I think) better handles the additional case that a is removed and inserted into the document. The general idea would be to remove the dialog from the open dialogs list and kill its closewatcher when the dialog is removed from the doc, and vice versa. I'm still working on it, but I do think there might still be some cases that this PR doesn't cover. Perhaps let me get that CL into working shape and then I can come back here and reconcile it with this PR?

Feel free to give me a shout if you want to explain what you think I'm missing and I can probably work out the missing piece myself.

mfreed7 · 2025-02-14T20:07:51Z

Feel free to give me a shout if you want to explain what you think I'm missing and I can probably work out the missing piece myself.

Alright, I think I'm happy with the latest Chromium CL behavior. I've added more corner cases to the the-dialog-element/dialog-closedby.html test that hopefully exercises many more weird situations. E.g. calling showModal() or close() from the focusin handler that gets called when focus is restored while running close(), or from the beforetoggle event, etc.

I think this is the end state that seems to make the most sense:

Define "do cleanup" to be the removal of dialog from the document's "open dialogs list", and destroying/nullifying the dialog's close watcher.
Define "do setup" to be the opposite of that (add to the dialog list and create the close watcher).
When the dialog's open attribute is removed while the dialog is connected, "do cleanup".
When a dialog with the open attribute is removed from the document (and a state preserving atomic move is not in progress), "do cleanup".
When the dialog's open attribute is added while the dialog is connected, "do setup".
When a dialog with the open attribute is inserted into the document (and a state preserving atomic move is not in progress), "do setup".
Make sure to "do cleanup" prior to performing the "focus the previously focused element" algorithm in .close().

Note that if we do the above, and before landing some version of #10124, there will still be this list of behaviors that are still "different" when removing the open attribute as compared to calling .close().

See more discussion here: whatwg/html#10954 In particular, this comment should summarize the end-state after this CL lands: whatwg/html#10954 (comment) Essentially, the spec says to remove a dialog from the open dialogs list when the dialog is removed from the document: https://html.spec.whatwg.org/multipage/interactive-elements.html#dom-dialog-requestclose:~:text=Remove%20removedNode%20from%20removedNode%27s%20node%20document%27s%20open%20dialogs%20list But it does not say what to do when a dialog is inserted into the document that has the `open` attribute, however. It also doesn't correctly handle the distinction between connected and disconnected dialogs. This CL adds insertion steps that re-add dialogs to the open dialogs list, and re-create the close watcher. Plus tests. Lots of tests. Bug: 376516550 Change-Id: Ie70d63287e26c4e5f4a0a200205f78e914e6a220 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6259116 Reviewed-by: Joey Arhar <[email protected]> Commit-Queue: Joey Arhar <[email protected]> Auto-Submit: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/main@{#1422181}

When the dialogs open attribute is removed: 1. Remove dialog from the document's open dialogs list. 2. Destroy and nullify dialog's close watcher This also adds an assertion to the start of 'set the dialog close watcher' that dialog's close watcher is null.

Address review comments

…e changed steps

lukewarlow · 2025-02-25T16:21:28Z

Define "do cleanup" to be the removal of dialog from the document's "open dialogs list", and destroying/nullifying the dialog's close watcher.
Define "do setup" to be the opposite of that (add to the dialog list and create the close watcher).
When the dialog's open attribute is removed while the dialog is connected, "do cleanup".
When the dialog's open attribute is added while the dialog is connected, "do setup".

Done all of the above

When a dialog with the open attribute is removed from the document (and a state preserving atomic move is not in progress), "do cleanup".
When a dialog with the open attribute is inserted into the document (and a state preserving atomic move is not in progress), "do setup".

Done the above aside from the state preserving atomic move checks because that isn't specced yet (#10657 will need updating)

Make sure to "do cleanup" prior to performing the "focus the previously focused element" algorithm in .close().

I don't think this is needed because close removes the open attribute which will trigger the attribute change steps. Likewise we don't need to run "do setup" from show or showModal()

source

mfreed7

This looks good to me, modulo a few comments. Thanks for making the changes.

source

mfreed7 · 2025-02-25T16:48:24Z

source

@@ -62567,9 +62576,6 @@ interface <dfn interface>HTMLDialogElement</dfn> : <span>HTMLElement</span> {

   <li><p>Set <span>is modal</span> of <var>subject</var> to false.</p></li>

-   <li><p><span data-x="list remove">Remove</span> <var>subject</var> from <var>subject</var>'s


So perhaps it's the same behavior, but Chromium's implementation actually skips over the special processing within the attribute change steps, and then does do the cleanup stuff here:

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/html_dialog_element.cc;l=175;drc=20799f4c32d950ce93d495f44eec648400f38a19

Note how the is_closing_ variable is used. So I think that this may work as-written, I can't be sure because it's different from the implementation.

mfreed7 · 2025-02-25T16:49:19Z

source

@@ -62595,19 +62601,6 @@ interface <dfn interface>HTMLDialogElement</dfn> : <span>HTMLElement</span> {
   <li><p><span>Queue an element task</span> on the <span>user interaction task source</span> given the
   <var>subject</var> element to <span data-x="concept-event-fire">fire an event</span> named
   <code data-x="event-close">close</code> at <var>subject</var>.</p></li>
-
-   <li>


Ditto above comment

mfreed7 · 2025-02-25T16:50:18Z

source

+   <span>node document</span>'s <span>open dialogs list</span>.</p></li>
+
+   <li>
+    <p>If <var>subject</var>'s <span data-x="dialog-close-watcher">close watcher</span> is not null,


I think this doesn't need the if and this should be an Assert instead.

(To verify this, I've put up this Chromium CL. Assuming it passes and lands, I'll stand by my statement above. 😄 )

I've made that change (can revert it if it doesn't work out).

So I'm still battling through test failures there. I can keep going, and perhaps find fixes, but perhaps the better approach is to keep the spec as you had it, and keep the if() rather than assert. Sorry.

No worries I can revert easy enough.

…atcher when removed, a=testonly Automatic update from web-platform-tests Handle the open dialogs list and close watcher when removed See more discussion here: whatwg/html#10954 In particular, this comment should summarize the end-state after this CL lands: whatwg/html#10954 (comment) Essentially, the spec says to remove a dialog from the open dialogs list when the dialog is removed from the document: https://html.spec.whatwg.org/multipage/interactive-elements.html#dom-dialog-requestclose:~:text=Remove%20removedNode%20from%20removedNode%27s%20node%20document%27s%20open%20dialogs%20list But it does not say what to do when a dialog is inserted into the document that has the `open` attribute, however. It also doesn't correctly handle the distinction between connected and disconnected dialogs. This CL adds insertion steps that re-add dialogs to the open dialogs list, and re-create the close watcher. Plus tests. Lots of tests. Bug: 376516550 Change-Id: Ie70d63287e26c4e5f4a0a200205f78e914e6a220 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6259116 Reviewed-by: Joey Arhar <[email protected]> Commit-Queue: Joey Arhar <[email protected]> Auto-Submit: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/main@{#1422181} -- wpt-commits: 68c405e14856d3a9f9264adc8b3df6de42af3fe3 wpt-pr: 50813

…atcher when removed, a=testonly Automatic update from web-platform-tests Handle the open dialogs list and close watcher when removed See more discussion here: whatwg/html#10954 In particular, this comment should summarize the end-state after this CL lands: whatwg/html#10954 (comment) Essentially, the spec says to remove a dialog from the open dialogs list when the dialog is removed from the document: https://html.spec.whatwg.org/multipage/interactive-elements.html#dom-dialog-requestclose:~:text=Remove%20removedNode%20from%20removedNode%27s%20node%20document%27s%20open%20dialogs%20list But it does not say what to do when a dialog is inserted into the document that has the `open` attribute, however. It also doesn't correctly handle the distinction between connected and disconnected dialogs. This CL adds insertion steps that re-add dialogs to the open dialogs list, and re-create the close watcher. Plus tests. Lots of tests. Bug: 376516550 Change-Id: Ie70d63287e26c4e5f4a0a200205f78e914e6a220 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6259116 Reviewed-by: Joey Arhar <jarharchromium.org> Commit-Queue: Joey Arhar <jarharchromium.org> Auto-Submit: Mason Freed <masonfchromium.org> Cr-Commit-Position: refs/heads/main{#1422181} -- wpt-commits: 68c405e14856d3a9f9264adc8b3df6de42af3fe3 wpt-pr: 50813 UltraBlame original commit: 6c706603ebb5d32380772ecf94a07ea845636f88

…atcher when removed, a=testonly Automatic update from web-platform-tests Handle the open dialogs list and close watcher when removed See more discussion here: whatwg/html#10954 In particular, this comment should summarize the end-state after this CL lands: whatwg/html#10954 (comment) Essentially, the spec says to remove a dialog from the open dialogs list when the dialog is removed from the document: https://html.spec.whatwg.org/multipage/interactive-elements.html#dom-dialog-requestclose:~:text=Remove%20removedNode%20from%20removedNode%27s%20node%20document%27s%20open%20dialogs%20list But it does not say what to do when a dialog is inserted into the document that has the `open` attribute, however. It also doesn't correctly handle the distinction between connected and disconnected dialogs. This CL adds insertion steps that re-add dialogs to the open dialogs list, and re-create the close watcher. Plus tests. Lots of tests. Bug: 376516550 Change-Id: Ie70d63287e26c4e5f4a0a200205f78e914e6a220 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6259116 Reviewed-by: Joey Arhar <[email protected]> Commit-Queue: Joey Arhar <[email protected]> Auto-Submit: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/main@{#1422181} -- wpt-commits: 68c405e14856d3a9f9264adc8b3df6de42af3fe3 wpt-pr: 50813

lukewarlow marked this pull request as draft January 27, 2025 20:18

lukewarlow force-pushed the remove-dialog-open-clear-list branch from b33a63f to 21886e7 Compare January 27, 2025 20:28

lukewarlow changed the title ~~Remove dialog from open dialogs list when open attribute removed~~ Add attribute changed steps to dialog element Jan 27, 2025

lukewarlow marked this pull request as ready for review January 27, 2025 20:31

domenic added the do not merge yet Pull request must not be merged per rationale in comment label Jan 28, 2025

lukewarlow mentioned this pull request Jan 28, 2025

Close dialog elements when the open attribute is removed #10124

Open

5 tasks

domenic mentioned this pull request Jan 29, 2025

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

Open

domenic reviewed Jan 30, 2025

View reviewed changes

source Outdated Show resolved Hide resolved

source Outdated Show resolved Hide resolved

source Outdated Show resolved Hide resolved

domenic added topic: dialog The <dialog> element and removed do not merge yet Pull request must not be merged per rationale in comment labels Jan 30, 2025

domenic mentioned this pull request Jan 30, 2025

Dialog processing model has gotten disorganized #10963

Closed

lukewarlow force-pushed the remove-dialog-open-clear-list branch from 6cc5176 to 1eca429 Compare February 1, 2025 19:08

lukewarlow force-pushed the remove-dialog-open-clear-list branch from 645374f to 376c837 Compare February 3, 2025 12:23

smaug---- reviewed Feb 7, 2025

View reviewed changes

source Outdated Show resolved Hide resolved

smaug---- reviewed Feb 7, 2025

View reviewed changes

source Outdated Show resolved Hide resolved

past mentioned this pull request Feb 7, 2025

Upcoming WHATNOT meeting on 2025-02-06 #10972

Closed

mfreed7 mentioned this pull request Feb 10, 2025

Fix dialog requestClose() to handle edge case #10983

Closed

6 tasks

lukewarlow marked this pull request as draft February 11, 2025 15:42

lukewarlow commented Feb 12, 2025

View reviewed changes

lukewarlow marked this pull request as ready for review February 12, 2025 12:31

past mentioned this pull request Feb 13, 2025

Upcoming WHATNOT meeting on 2025-02-13 #11010

Closed

chromium-wpt-export-bot mentioned this pull request Feb 19, 2025

Handle the open dialogs list and close watcher when removed web-platform-tests/wpt#50813

Merged

past mentioned this pull request Feb 20, 2025

Upcoming WHATNOT meeting on 2025-02-20 #11026

Closed

lukewarlow added 7 commits February 25, 2025 15:01

Replace assert in set the dialog close watcher with an early return

6d4d474

Add dialog attribute change steps when adding open attribute

68cf6dc

Address review comments

Run specfmt

855f57d

Define dialog cleanup and setup steps and call them from the attribut…

f38d4df

…e changed steps

Call dialog cleanup steps from dialog removing steps

46aaabc

Define dialog HTML element insertion steps and call dialog setup steps

78b3dc0

lukewarlow force-pushed the remove-dialog-open-clear-list branch from 931fd03 to 78b3dc0 Compare February 25, 2025 16:11

lukewarlow changed the title ~~Add attribute changed steps to dialog element~~ Update dialog to minimally handle open attribute mutations Feb 25, 2025

lukewarlow commented Feb 25, 2025

View reviewed changes

source Show resolved Hide resolved

lukewarlow force-pushed the remove-dialog-open-clear-list branch from 2c146e5 to 78b3dc0 Compare February 25, 2025 16:30

mfreed7 reviewed Feb 25, 2025

View reviewed changes

mfreed7 mentioned this pull request Feb 25, 2025

State-preserving atomic move integration #10657

Open

5 tasks

Replace early return with assert

be43034

lukewarlow force-pushed the remove-dialog-open-clear-list branch from 09acb26 to be43034 Compare February 26, 2025 16:21

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update dialog to minimally handle open attribute mutations #10954

Update dialog to minimally handle open attribute mutations #10954

lukewarlow commented Jan 27, 2025 •

edited by pr-preview bot

Loading

domenic commented Jan 28, 2025

domenic left a comment

lukewarlow commented Jan 30, 2025

lukewarlow commented Feb 1, 2025

lukewarlow commented Feb 2, 2025

mfreed7 commented Feb 7, 2025

lukewarlow Feb 12, 2025

lukewarlow commented Feb 12, 2025

lukewarlow commented Feb 12, 2025

mfreed7 commented Feb 13, 2025

lukewarlow commented Feb 13, 2025

mfreed7 commented Feb 14, 2025

lukewarlow commented Feb 25, 2025

mfreed7 left a comment

mfreed7 Feb 25, 2025

mfreed7 Feb 25, 2025

mfreed7 Feb 25, 2025

lukewarlow Feb 25, 2025

mfreed7 Feb 25, 2025

lukewarlow Feb 25, 2025

		@@ -62567,9 +62576,6 @@ interface <dfn interface>HTMLDialogElement</dfn> : <span>HTMLElement</span> {

		<li><p>Set <span>is modal</span> of <var>subject</var> to false.</p></li>

		<li><p><span data-x="list remove">Remove</span> <var>subject</var> from <var>subject</var>'s

Update dialog to minimally handle open attribute mutations #10954

Are you sure you want to change the base?

Update dialog to minimally handle open attribute mutations #10954

Conversation

lukewarlow commented Jan 27, 2025 • edited by pr-preview bot Loading

domenic commented Jan 28, 2025

domenic left a comment

Choose a reason for hiding this comment

lukewarlow commented Jan 30, 2025

lukewarlow commented Feb 1, 2025

lukewarlow commented Feb 2, 2025

mfreed7 commented Feb 7, 2025

lukewarlow Feb 12, 2025

Choose a reason for hiding this comment

lukewarlow commented Feb 12, 2025

lukewarlow commented Feb 12, 2025

mfreed7 commented Feb 13, 2025

lukewarlow commented Feb 13, 2025

mfreed7 commented Feb 14, 2025

lukewarlow commented Feb 25, 2025

mfreed7 left a comment

Choose a reason for hiding this comment

mfreed7 Feb 25, 2025

Choose a reason for hiding this comment

mfreed7 Feb 25, 2025

Choose a reason for hiding this comment

mfreed7 Feb 25, 2025

Choose a reason for hiding this comment

lukewarlow Feb 25, 2025

Choose a reason for hiding this comment

mfreed7 Feb 25, 2025

Choose a reason for hiding this comment

lukewarlow Feb 25, 2025

Choose a reason for hiding this comment

lukewarlow commented Jan 27, 2025 •

edited by pr-preview bot

Loading