-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update dialog to minimally handle open attribute mutations #10954
base: main
Are you sure you want to change the base?
Conversation
b33a63f
to
21886e7
Compare
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
I've opened web-platform-tests/wpt#50393 which fails in a browser which follows the current spec:
|
6cc5176
to
1eca429
Compare
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 ) |
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). |
645374f
to
376c837
Compare
FYI, see comments at #10953 (comment) and after. |
source
Outdated
@@ -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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)
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?). |
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 |
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. |
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 <jarhar@chromium.org> Commit-Queue: Joey Arhar <jarhar@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1422181}
931fd03
to
78b3dc0
Compare
Done all of the above
Done the above aside from the state preserving atomic move checks because that isn't specced yet (#10657 will need updating)
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() |
2c146e5
to
78b3dc0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me, modulo a few comments. Thanks for making the changes.
source
Outdated
@@ -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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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:
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.
source
Outdated
@@ -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> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ditto above comment
09acb26
to
be43034
Compare
…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 <jarhar@chromium.org> Commit-Queue: Joey Arhar <jarhar@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> 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 <jarhar@chromium.org> Commit-Queue: Joey Arhar <jarhar@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> 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 <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 <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 <jarhar@chromium.org> Commit-Queue: Joey Arhar <jarhar@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1422181} -- wpt-commits: 68c405e14856d3a9f9264adc8b3df6de42af3fe3 wpt-pr: 50813
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
I just looked into this and I think we don't actually need any changes here. This is because of a difference in spec layout vs chromium impl. In chrome the RemovedFrom and InsertedInto methods are invoked and the then there's early returns for state preserving atomic move operations. However, the spec went a different approach and defined separate moving steps. Because we don't have moving steps defined for dialog, nothing happens to it which is expected. @mfreed7 @domfarolino does this make sense to you or am I missing something? |
This reverts commit e7096df.
be43034
to
b5cc2c5
Compare
That sounds right to me. I just wanted to highlight it since I did have to handle this case in code, and assumed it would therefore have spec impact. I'm not the |
Update dialog to minimally handle open attribute mutations
We define two new algorithms for dialog:
Dialog cleanup steps which:
Dialog setup steps which:
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
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#50432https://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
(See WHATWG Working Mode: Changes for more details.)
/interactive-elements.html ( diff )