Fix dialog closedby and requestClose() (take 2)#11326
Conversation
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
This reverts commit e7096df.
Dialog setup steps: - Move set the dialog close watcher to step 1 - Add early return when dialog is not connected as a new step 2 (before adding to dialog light dismiss list). Dialog cleanup steps: - Remove assertion - Remove disposing of close watcher. Dialog attribute change steps: - Remove connected check from steps 3 and 4. Dialog insertion steps: - Remove connected check added in previous commit.
|
@mfreed7 would you kindly check through this - I believe this closely aligns to the Chrome behaviour, but it would be great if you could confirm. @annevk you also might want to take a look as we've discussed this in #11230 & #11278. Additionally @domenic you might want to take a look, this involves close watchers. |
|
Does https://github.com/web-platform-tests/wpt/pull/50393/files provide anything new that's not already tested? |
mfreed7
left a comment
There was a problem hiding this comment.
Thanks for putting this together! I believe this matches the Chromium implementation, modulo the few comments I added.
| <li><p>If <var>removedNode</var> has an <code data-x="attr-dialog-open">open</code> attribute, | ||
| then run the <span>dialog cleanup steps</span> given <var>removedNode</var>.</p></li> | ||
|
|
||
| <li><p>If <var>removedNode</var>'s <span>node document</span>'s <span>top layer</span> <span |
There was a problem hiding this comment.
Can you remind me why we only do these two steps for element removal, and not for open attribute removal?
There was a problem hiding this comment.
Note that although Chromium implements #10124, it's not shipped yet, just behind experimental web platform features. And #10124 does more than just cleanup steps + top layer removal + is modal -> false; it does the whole "close a dialog" algorithm.
So it sounds like we should merge this PR as-is, as it aligns with what Chromium currently ships and is an improvement over the current spec which is buggy in lots of ways. Then, we should work on making the behavior more sane, which would include at a minimum aligning removal + attribute changed, but could go all the way to making removal and/or attribute changed do a full close (per #10124).
There was a problem hiding this comment.
This LGTM with one more typography fix. However, can you help reassure me that everything has web platform tests? For one example, I don't see fully active checks in the Chromium implementation. (They might be hidden in a base class or something.)
I'll also give people a few more days to review in case, and plan on merging next Monday Japan time if you reassure me on the test coverage.
| <li><p>If <var>removedNode</var> has an <code data-x="attr-dialog-open">open</code> attribute, | ||
| then run the <span>dialog cleanup steps</span> given <var>removedNode</var>.</p></li> | ||
|
|
||
| <li><p>If <var>removedNode</var>'s <span>node document</span>'s <span>top layer</span> <span |
There was a problem hiding this comment.
Note that although Chromium implements #10124, it's not shipped yet, just behind experimental web platform features. And #10124 does more than just cleanup steps + top layer removal + is modal -> false; it does the whole "close a dialog" algorithm.
So it sounds like we should merge this PR as-is, as it aligns with what Chromium currently ships and is an improvement over the current spec which is buggy in lots of ways. Then, we should work on making the behavior more sane, which would include at a minimum aligning removal + attribute changed, but could go all the way to making removal and/or attribute changed do a full close (per #10124).
The tests have somewhat organically grown due to the lack of specification around this, and in addition a lot of this is "action at a distance", so they're not neatly organised but:
We could probably improve coverage, or at least organise it so it is more explicitly aligned to these spec changes, but overall I feel confident with the tests in place, but happy to take suggestions or guidance if you feel it's insufficient. |
|
Well, I'm especially curious if there are tests for fa98a1c. |
|
@zcorpan can you re-review to clear the "changes requested" that is blocking this from landing? |
|
Is there anything left needed to get this landed (have been out of the loop so not sure what the state of this PR is). It would be good to get the spec fixed up so further implementations can be done (e.g. webkit, servo, ladybird) in a way that we can be more confident. |
|
I would prefer to have tests for the latest changes, in particular fa98a1c. @lukewarlow, is that something you can help with? |
|
Yeah as part of the WebKit implementation I can add additional tests. I'll be honest though I'm not immediately clear on what a "non fully-active" document actually is that like document.implementation stuff? |
|
The three major sources of non-fully active are: synthetic documents (e.g. |
This is a continuation of #10954 to update the
dialogelement to handle changes to the open attribute. It includes:openattribute is presentopenattribute is presentFixes #10953, #10982, #11259.
(See WHATWG Working Mode: Changes for more details.)
/interactive-elements.html ( diff )