Add dialog light dismiss behavior #10737

mfreed7 · 2024-10-31T23:17:09Z

This adds a few things:

A closedby attribute that can be used to control the light dismiss behavior of dialogs:
1. <dialog closedby=none> - no user-triggered closing of dialogs at all.
2. <dialog closedby=closerequest> - user pressing ESC (or other close trigger) closes the dialog
3. <dialog closedby=any> - user clicking outside the dialog, or pressing ESC, closes the dialog. Akin to popover=auto behavior.
4. <dialog> - i.e. no closedby attribute - default/old behavior. Behaves like closedby=closerequest for modal dialogs, and closedby=none for modeless dialogs.
This PR also (per the request) adds a dialog.requestClose() which fires the cancel event, and then (if that isn't cancelled) fires the close event and closes the dialog.
I also consolidated the "light dismiss" activities into one algorithm, which will need to be called by Add popover light dismiss integration w3c/pointerevents#460 if that ever gets some attention.

Some interesting related links:

WIP dialog closedby attribute spec #10157 - much of this PR was lifted from @lukewarlow's PR
Add light dismiss functionality to <dialog> #9373 - the WHATWG discussion
Bikeshed a name for "light dismiss for dialog" openui/open-ui#834 - the OpenUI discussion
Naming for the *attribute* to enable "light dismiss for dialog" openui/open-ui#960 - naming discussion to get to closedby
Naming for the *value* for the attribute that means "just close with ESC" openui/open-ui#961 - naming discussion to get to closerequest

At least two implementers are interested (and none opposed):
- Chromium
- …
Tests are written and can be reviewed and commented upon at:
- https://wpt.fyi/results/html/semantics/interactive-elements/the-dialog-element?label=master&label=experimental&aligned&q=dialog-closedby.tentative.html%20or%20dialog-popover-closedby-complex.tentative.html%20or%20dialog-popover-closedby-simple.tentative.html%20or%20dialog-requestclose.tentative.html
Implementation bugs are filed:
- Chromium: https://crbug.com/376516550
- Gecko: …
- WebKit: …
MDN issue is filed: …
The top of this comment includes a clear commit message to use.

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

/dnd.html ( diff )
/index.html ( diff )
/indices.html ( diff )
/infrastructure.html ( diff )
/interaction.html ( diff )
/interactive-elements.html ( diff )
/popover.html ( diff )

domenic · 2024-11-01T08:14:59Z

This is exciting! Unfortunately I am going OOO for a week starting ~now, so won't get a chance to review too soon. Hopefully others will be able to help with some reviews, but I would like to get a chance to carefully review the close watcher integration, etc. before this lands.

Would you mind commenting on what approach you took to the mutability of the closedby attribute? We discussed that a bit in #9373, and I think we came up with a tentative proposal, but I'm not sure it was battle-tested.

keithamus · 2024-11-01T12:03:59Z

Would you mind commenting on what approach you took to the mutability of the closedby attribute? We discussed that a bit in #9373, and I think we came up with a tentative proposal, but I'm not sure it was battle-tested.

Looks like CloseWatchers get a mutable enabled value, which is toggled whenever closedby is set to the applicable values - when false it skips the events and returns early. IMO this seems to nicely side-skirt the stacking issues around mutation of the attribute without adding lots of complexity in either the consuming elements and/or having some messy algorithms to insert mid-way into a stack.

keithamus

This looks great to me!

source

mfreed7 · 2024-11-01T16:07:01Z

This is exciting! Unfortunately I am going OOO for a week starting ~now, so won't get a chance to review too soon. Hopefully others will be able to help with some reviews, but I would like to get a chance to carefully review the close watcher integration, etc. before this lands.

That's totally fine - no rush. I did this one in the opposite order that I usually do: spec first, prototype after. So I'm moving on to prototype it now, which might reveal other flaws. But I thought since @lukewarlow had gotten the spec into such decent shape, that I'd clean it up and open the PR in case folks saw other flaws there that I could address in the prototype.

Would you mind commenting on what approach you took to the mutability of the closedby attribute? We discussed that a bit in #9373, and I think we came up with a tentative proposal, but I'm not sure it was battle-tested.

As @keithamus said, I just kept what @lukewarlow did in the original PR, and used a new enabled state on CloseWatcher. I haven't implemented that yet, but it seems reasonably straightforward. But let me know if you see any flaws.

source

annevk · 2024-11-05T09:59:35Z

source

+  <p>The <code data-x="attr-dialog-closedby">closedby</code> attribute's <i data-x="invalid value
+  default">invalid value default</i> and <i data-x="missing value default">missing value
+  default</i> are both the <dfn data-x="attr-closedby-auto-state">Auto</dfn> state. The <span
+  data-x="attr-closedby-auto-state">auto</span> state matches <span
+  data-x="attr-closedby-closerequest-state">closerequest</span> when the element is modal;
+  otherwise <span data-x="attr-closedby-none-state">none</span>.</p>


There's very inconsistent spelling of states here. They should match the capitalization and words of how they are introduced. And should typically be followed by the word state (though that's not linked).

Also, perhaps the statement of fact is better as a note?

There's very inconsistent spelling of states here. They should match the capitalization and words of how they are introduced. And should typically be followed by the word state (though that's not linked).

Yep, I agree. I fixed them all up, I think. Please let me know if you see any others I missed. All are now lowercase.

Also, perhaps the statement of fact is better as a note?

Sorry - can you help me understand this? Which "statement of fact"?

This CL puts the feature flag in place, adds (flag guarded) closedBy and requestClose() methods to <dialog>, connects the pointer events handling to a new dialog light dismiss method, and adds a basic set of tests. None of the actual functionality is here yet, this is just a shell. Subsequent CLs will flesh out the behavior. See spec PR for details: whatwg/html#10737 Here's the chromestatus: https://chromestatus.com/feature/5097714453577728 Bug: 376516550 Change-Id: I3727ca21476a2a3340fd18597970395d64ef7176

This CL puts the feature flag in place, adds (flag guarded) closedBy and requestClose() methods to <dialog>, connects the pointer events handling to a new dialog light dismiss method, and adds a basic set of tests. None of the actual functionality is here yet, this is just a shell. Subsequent CLs will flesh out the behavior. See spec PR for details: whatwg/html#10737 Here's the chromestatus: https://chromestatus.com/feature/5097714453577728 Bug: 376516550 Change-Id: I3727ca21476a2a3340fd18597970395d64ef7176 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5985491 Commit-Queue: Mason Freed <[email protected]> Reviewed-by: David Baron <[email protected]> Cr-Commit-Position: refs/heads/main@{#1378633}

This implements reflection of `closedBy` including the "limited to known values" behavior. See spec PR for details: whatwg/html#10737 Bug: 376516550 Change-Id: Iddefd573fe19fd39f4b3aebe13390235fea969b9

…ht dismiss [1/N], a=testonly Automatic update from web-platform-tests Implement basic structure for dialog light dismiss [1/N] This CL puts the feature flag in place, adds (flag guarded) closedBy and requestClose() methods to <dialog>, connects the pointer events handling to a new dialog light dismiss method, and adds a basic set of tests. None of the actual functionality is here yet, this is just a shell. Subsequent CLs will flesh out the behavior. See spec PR for details: whatwg/html#10737 Here's the chromestatus: https://chromestatus.com/feature/5097714453577728 Bug: 376516550 Change-Id: I3727ca21476a2a3340fd18597970395d64ef7176 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5985491 Commit-Queue: Mason Freed <[email protected]> Reviewed-by: David Baron <[email protected]> Cr-Commit-Position: refs/heads/main@{#1378633} -- wpt-commits: 1d5037cc3ff4524fd5d9f1a461afd20aebbb0839 wpt-pr: 48976

This implements reflection of `closedBy` including the "limited to known values" behavior. See spec PR for details: whatwg/html#10737 Bug: 376516550 Change-Id: Iddefd573fe19fd39f4b3aebe13390235fea969b9

This implements reflection of `closedBy` including the "limited to known values" behavior. See spec PR for details: whatwg/html#10737 Bug: 376516550 Change-Id: Iddefd573fe19fd39f4b3aebe13390235fea969b9 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5988652 Commit-Queue: Mason Freed <[email protected]> Reviewed-by: David Baron <[email protected]> Commit-Queue: David Baron <[email protected]> Auto-Submit: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/main@{#1379228}

This enables `closedby=none` to *stop* the dialog from closing when the ESC key (or other close signal) is received. See spec PR for details: whatwg/html#10737 Bug: 376516550 Change-Id: I0bf7fc7a50acaffb89e183fe6e19f411de4da576 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5990171 Reviewed-by: David Baron <[email protected]> Commit-Queue: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/main@{#1379279}

…ht dismiss [1/N], a=testonly Automatic update from web-platform-tests Implement basic structure for dialog light dismiss [1/N] This CL puts the feature flag in place, adds (flag guarded) closedBy and requestClose() methods to <dialog>, connects the pointer events handling to a new dialog light dismiss method, and adds a basic set of tests. None of the actual functionality is here yet, this is just a shell. Subsequent CLs will flesh out the behavior. See spec PR for details: whatwg/html#10737 Here's the chromestatus: https://chromestatus.com/feature/5097714453577728 Bug: 376516550 Change-Id: I3727ca21476a2a3340fd18597970395d64ef7176 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5985491 Commit-Queue: Mason Freed <[email protected]> Reviewed-by: David Baron <[email protected]> Cr-Commit-Position: refs/heads/main@{#1378633} -- wpt-commits: 1d5037cc3ff4524fd5d9f1a461afd20aebbb0839 wpt-pr: 48976

…alog closedBy [2/N], a=testonly Automatic update from web-platform-tests Add attribute reflection behavior for dialog closedBy [2/N] This implements reflection of `closedBy` including the "limited to known values" behavior. See spec PR for details: whatwg/html#10737 Bug: 376516550 Change-Id: Iddefd573fe19fd39f4b3aebe13390235fea969b9 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5988652 Commit-Queue: Mason Freed <[email protected]> Reviewed-by: David Baron <[email protected]> Commit-Queue: David Baron <[email protected]> Auto-Submit: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/main@{#1379228} -- wpt-commits: 28946b88d5b2e037bb2506ae4984e8725ba5560b wpt-pr: 48989

This implements dialog.requestClose() and adds a test. See spec PR for details: whatwg/html#10737 Bug: 376516550 Change-Id: Iaac3d89c28844d2b54ff5b1a7b68dc356d1fd172

source

…=testonly Automatic update from web-platform-tests Implement dialog.requestClose() [4/N] This implements dialog.requestClose() and adds a test. See spec PR for details: whatwg/html#10737 Bug: 376516550 Change-Id: Iaac3d89c28844d2b54ff5b1a7b68dc356d1fd172 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5991017 Commit-Queue: Mason Freed <masonfchromium.org> Reviewed-by: David Baron <dbaronchromium.org> Auto-Submit: Mason Freed <masonfchromium.org> Cr-Commit-Position: refs/heads/main{#1380450} -- wpt-commits: 97a34c26ea3a3bfeacc0f40fc733d464c3f4d377 wpt-pr: 49050 UltraBlame original commit: 4caf91ac4ff80bb8e77480009090bbaa21eae410

…alog closedBy [2/N], a=testonly Automatic update from web-platform-tests Add attribute reflection behavior for dialog closedBy [2/N] This implements reflection of `closedBy` including the "limited to known values" behavior. See spec PR for details: whatwg/html#10737 Bug: 376516550 Change-Id: Iddefd573fe19fd39f4b3aebe13390235fea969b9 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5988652 Commit-Queue: Mason Freed <[email protected]> Reviewed-by: David Baron <[email protected]> Commit-Queue: David Baron <[email protected]> Auto-Submit: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/main@{#1379228} -- wpt-commits: 28946b88d5b2e037bb2506ae4984e8725ba5560b wpt-pr: 48989

…=testonly Automatic update from web-platform-tests Implement dialog.requestClose() [4/N] This implements dialog.requestClose() and adds a test. See spec PR for details: whatwg/html#10737 Bug: 376516550 Change-Id: Iaac3d89c28844d2b54ff5b1a7b68dc356d1fd172 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5991017 Commit-Queue: Mason Freed <[email protected]> Reviewed-by: David Baron <[email protected]> Auto-Submit: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/main@{#1380450} -- wpt-commits: 97a34c26ea3a3bfeacc0f40fc733d464c3f4d377 wpt-pr: 49050

…ctual click outside part) 5/5, a=testonly Automatic update from web-platform-tests Add dialog light dismiss behavior (the actual click outside part) 5/5 This adds to the prior CLs to actually allow "click outside" to function as a light dismiss trigger. See spec PR for details: whatwg/html#10737 Bug: 376516550 Change-Id: I62158e092de9acac182777f2ad9864e818128907 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6013845 Commit-Queue: David Baron <[email protected]> Reviewed-by: David Baron <[email protected]> Auto-Submit: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/main@{#1383792} -- wpt-commits: 5420c40fa454adde8aa1e810ddb97ed79fd15c0e wpt-pr: 49201

1. The prior implementation ignored the argument to requestClose. With this CL, requestClose(string) stores away string and then returns it from the CloseWatcher close event. 2. If the dialog's closedBy state is None (either explicitly or through the "Auto" state), requestClose throws an exception. I also added a more significant set of tests for requestClose() in all states. This goes along with recent discussion about throwing exceptions if requestClose() is called when the dialog isn't in the right state, relative to closedBy: whatwg/html#10164 (comment) The spec PR has been updated accordingly: whatwg/html#10737 Bug: 376516550 Change-Id: I023845844e6afb4da9a71637d517ac78d2861329

1. The prior implementation ignored the argument to requestClose. With this CL, requestClose(string) stores away string and then returns it from the CloseWatcher close event. 2. If the dialog's closedBy state is None (either explicitly or through the "Auto" state), requestClose throws an exception. I also added a more significant set of tests for requestClose() in all states. This goes along with recent discussion about throwing exceptions if requestClose() is called when the dialog isn't in the right state, relative to closedBy: whatwg/html#10164 (comment) The spec PR has been updated accordingly: whatwg/html#10737 Bug: 376516550 Change-Id: I023845844e6afb4da9a71637d517ac78d2861329 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6026242 Auto-Submit: Mason Freed <[email protected]> Reviewed-by: David Baron <[email protected]> Commit-Queue: David Baron <[email protected]> Cr-Commit-Position: refs/heads/main@{#1384345}

…ctual click outside part) 5/5, a=testonly Automatic update from web-platform-tests Add dialog light dismiss behavior (the actual click outside part) 5/5 This adds to the prior CLs to actually allow "click outside" to function as a light dismiss trigger. See spec PR for details: whatwg/html#10737 Bug: 376516550 Change-Id: I62158e092de9acac182777f2ad9864e818128907 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6013845 Commit-Queue: David Baron <[email protected]> Reviewed-by: David Baron <[email protected]> Auto-Submit: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/main@{#1383792} -- wpt-commits: 5420c40fa454adde8aa1e810ddb97ed79fd15c0e wpt-pr: 49201

…=testonly Automatic update from web-platform-tests Fix dialog.requestClose() in two ways 1. The prior implementation ignored the argument to requestClose. With this CL, requestClose(string) stores away string and then returns it from the CloseWatcher close event. 2. If the dialog's closedBy state is None (either explicitly or through the "Auto" state), requestClose throws an exception. I also added a more significant set of tests for requestClose() in all states. This goes along with recent discussion about throwing exceptions if requestClose() is called when the dialog isn't in the right state, relative to closedBy: whatwg/html#10164 (comment) The spec PR has been updated accordingly: whatwg/html#10737 Bug: 376516550 Change-Id: I023845844e6afb4da9a71637d517ac78d2861329 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6026242 Auto-Submit: Mason Freed <[email protected]> Reviewed-by: David Baron <[email protected]> Commit-Queue: David Baron <[email protected]> Cr-Commit-Position: refs/heads/main@{#1384345} -- wpt-commits: 6f4f09f92913154e70e9214636ee0e60c65f5d05 wpt-pr: 49223

domenic

Sorry for the big delay! Overall this looks good, with the only really substantial suggestion being to move to making enabled an algorithm to avoid the attribute changed steps.

Do you have a link for the tests? I've found that writing comprehensive-feeling tests for close watcher stuff is hard (as you want to test at least two, sometimes more, nested). And then you have all the permutations of attribute values, what if someone modifies the attribute while it's closed, etc. In my experience, without tests it's quite difficult to make sure the behavior is reasonable.

For example, it'd be worth testing (maybe interactively, instead of in WPTs, at least at first) that you get reasonable user behavior in situations like one closedby=none dialog sandwiched in the middle of two closedby=any dialogs.

source

domenic · 2024-11-21T04:36:53Z

source

   <li><p>If <span>this</span> is not <span>connected</span>, then throw an
   <span>"<code>InvalidStateError</code>"</span> <code>DOMException</code>.</p></li>

+   <li><p>If <span>this</span>'s <span>node document</span> is not <span>fully active</span>, then
+   throw an <span>"<code>InvalidStateError</code>"</span> <code>DOMException</code>.</p></li>


What is the reasoning for this reordering?

Oh, I wasn't sure about that, thanks for asking. I don't think the ordering of these two steps matters, and it just seemed more logical to me to check first whether it was connected, and then check for a fully active owner document. I can put it back - no big deal.

source

mfreed7

Thanks for the very thorough review! I think I got everything, but let me know what I missed or did incorrectly.

source

mfreed7 · 2024-11-21T19:57:38Z

source

   <li><p>If <span>this</span> is not <span>connected</span>, then throw an
   <span>"<code>InvalidStateError</code>"</span> <code>DOMException</code>.</p></li>

+   <li><p>If <span>this</span>'s <span>node document</span> is not <span>fully active</span>, then
+   throw an <span>"<code>InvalidStateError</code>"</span> <code>DOMException</code>.</p></li>


Oh, I wasn't sure about that, thanks for asking. I don't think the ordering of these two steps matters, and it just seemed more logical to me to check first whether it was connected, and then check for a fully active owner document. I can put it back - no big deal.

source

mfreed7 · 2024-11-21T23:28:28Z

Sorry for the big delay! Overall this looks good, with the only really substantial suggestion being to move to making enabled an algorithm to avoid the attribute changed steps.

No problem, and thanks again!

Do you have a link for the tests? I've found that writing comprehensive-feeling tests for close watcher stuff is hard (as you want to test at least two, sometimes more, nested). And then you have all the permutations of attribute values, what if someone modifies the attribute while it's closed, etc. In my experience, without tests it's quite difficult to make sure the behavior is reasonable.
For example, it'd be worth testing (maybe interactively, instead of in WPTs, at least at first) that you get reasonable user behavior in situations like one closedby=none dialog sandwiched in the middle of two closedby=any dialogs.

So I've written tests for several levels of "nesting", including popover/dialog/popover/dialog with mixed modal/modeless dialogs (that's the -complex test). I also added just popover/dialog with different values of closedby (that's the -simple test). But I didn't include closedby permutations in the complex test. I can do that, if you think it'd be helpful.

…=testonly Automatic update from web-platform-tests Fix dialog.requestClose() in two ways 1. The prior implementation ignored the argument to requestClose. With this CL, requestClose(string) stores away string and then returns it from the CloseWatcher close event. 2. If the dialog's closedBy state is None (either explicitly or through the "Auto" state), requestClose throws an exception. I also added a more significant set of tests for requestClose() in all states. This goes along with recent discussion about throwing exceptions if requestClose() is called when the dialog isn't in the right state, relative to closedBy: whatwg/html#10164 (comment) The spec PR has been updated accordingly: whatwg/html#10737 Bug: 376516550 Change-Id: I023845844e6afb4da9a71637d517ac78d2861329 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6026242 Auto-Submit: Mason Freed <[email protected]> Reviewed-by: David Baron <[email protected]> Commit-Queue: David Baron <[email protected]> Cr-Commit-Position: refs/heads/main@{#1384345} -- wpt-commits: 6f4f09f92913154e70e9214636ee0e60c65f5d05 wpt-pr: 49223

domenic · 2024-11-22T09:29:17Z

Did you see my comments on #9373 (comment)? I guess we should figure out the desired behavior for nested dialogs over there...

mfreed7 · 2024-11-22T18:23:59Z

Did you see my comments on #9373 (comment)? I guess we should figure out the desired behavior for nested dialogs over there...

Nope, missed it until now. Thanks. I'll come back here when we have more clarity on the behavior.

…=testonly Automatic update from web-platform-tests Fix dialog.requestClose() in two ways 1. The prior implementation ignored the argument to requestClose. With this CL, requestClose(string) stores away string and then returns it from the CloseWatcher close event. 2. If the dialog's closedBy state is None (either explicitly or through the "Auto" state), requestClose throws an exception. I also added a more significant set of tests for requestClose() in all states. This goes along with recent discussion about throwing exceptions if requestClose() is called when the dialog isn't in the right state, relative to closedBy: whatwg/html#10164 (comment) The spec PR has been updated accordingly: whatwg/html#10737 Bug: 376516550 Change-Id: I023845844e6afb4da9a71637d517ac78d2861329 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6026242 Auto-Submit: Mason Freed <masonfchromium.org> Reviewed-by: David Baron <dbaronchromium.org> Commit-Queue: David Baron <dbaronchromium.org> Cr-Commit-Position: refs/heads/main{#1384345} -- wpt-commits: 6f4f09f92913154e70e9214636ee0e60c65f5d05 wpt-pr: 49223 UltraBlame original commit: 6b098292cbe3fd32f9a6e982d47edfdd882c84cc

…=testonly Automatic update from web-platform-tests Fix dialog.requestClose() in two ways 1. The prior implementation ignored the argument to requestClose. With this CL, requestClose(string) stores away string and then returns it from the CloseWatcher close event. 2. If the dialog's closedBy state is None (either explicitly or through the "Auto" state), requestClose throws an exception. I also added a more significant set of tests for requestClose() in all states. This goes along with recent discussion about throwing exceptions if requestClose() is called when the dialog isn't in the right state, relative to closedBy: whatwg/html#10164 (comment) The spec PR has been updated accordingly: whatwg/html#10737 Bug: 376516550 Change-Id: I023845844e6afb4da9a71637d517ac78d2861329 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6026242 Auto-Submit: Mason Freed <[email protected]> Reviewed-by: David Baron <[email protected]> Commit-Queue: David Baron <[email protected]> Cr-Commit-Position: refs/heads/main@{#1384345} -- wpt-commits: 6f4f09f92913154e70e9214636ee0e60c65f5d05 wpt-pr: 49223

annevk · 2024-11-28T15:12:44Z

source

+  [<span>CEReactions</span>] undefined <span data-x="dom-dialog-close">close</span>(optional DOMString returnValue = null);
+  [<span>CEReactions</span>] undefined <span data-x="dom-dialog-request-close">requestClose</span>(optional DOMString returnValue = null);


This is invalid IDL. You would have to change this to DOMString? for that to work, but I don't think we should be accepting null as a valid value here. What we had before was better. Undefined or the type is preferable to undefined, null, or the type, with undefined and null meaning the same thing in the latter case.

annevk · 2024-11-28T15:13:56Z

source

+   <li><p><span>Assert</span>: <var>event</var>'s <code
+   data-x="dom-Event-isTrusted">isTrusted</code> attribute is true.</p></li>
+
+   <li><p><span>Assert</span>: <var>event</var> is a <code>PointerEvent</code>.</p></li>


Why not make this algorithm take a PointerEvent and make it the responsibility of the caller?

…=testonly Automatic update from web-platform-tests Fix dialog.requestClose() in two ways 1. The prior implementation ignored the argument to requestClose. With this CL, requestClose(string) stores away string and then returns it from the CloseWatcher close event. 2. If the dialog's closedBy state is None (either explicitly or through the "Auto" state), requestClose throws an exception. I also added a more significant set of tests for requestClose() in all states. This goes along with recent discussion about throwing exceptions if requestClose() is called when the dialog isn't in the right state, relative to closedBy: whatwg/html#10164 (comment) The spec PR has been updated accordingly: whatwg/html#10737 Bug: 376516550 Change-Id: I023845844e6afb4da9a71637d517ac78d2861329 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6026242 Auto-Submit: Mason Freed <[email protected]> Reviewed-by: David Baron <[email protected]> Commit-Queue: David Baron <[email protected]> Cr-Commit-Position: refs/heads/main@{#1384345} -- wpt-commits: 6f4f09f92913154e70e9214636ee0e60c65f5d05 wpt-pr: 49223

…=testonly Automatic update from web-platform-tests Fix dialog.requestClose() in two ways 1. The prior implementation ignored the argument to requestClose. With this CL, requestClose(string) stores away string and then returns it from the CloseWatcher close event. 2. If the dialog's closedBy state is None (either explicitly or through the "Auto" state), requestClose throws an exception. I also added a more significant set of tests for requestClose() in all states. This goes along with recent discussion about throwing exceptions if requestClose() is called when the dialog isn't in the right state, relative to closedBy: whatwg/html#10164 (comment) The spec PR has been updated accordingly: whatwg/html#10737 Bug: 376516550 Change-Id: I023845844e6afb4da9a71637d517ac78d2861329 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6026242 Auto-Submit: Mason Freed <masonfchromium.org> Reviewed-by: David Baron <dbaronchromium.org> Commit-Queue: David Baron <dbaronchromium.org> Cr-Commit-Position: refs/heads/main{#1384345} -- wpt-commits: 6f4f09f92913154e70e9214636ee0e60c65f5d05 wpt-pr: 49223 UltraBlame original commit: 1f244e2980abb756ba68b021b1000a60e03d054e

keithamus reviewed Nov 1, 2024

View reviewed changes

source Outdated Show resolved Hide resolved

mfreed7 mentioned this pull request Nov 1, 2024

Support disabling CloseWatcher integration in <dialog> #10592

Open

annevk added addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest needs tests Moving the issue forward requires someone to write tests topic: dialog The <dialog> element labels Nov 5, 2024

annevk reviewed Nov 5, 2024

View reviewed changes

source Outdated Show resolved Hide resolved

annevk reviewed Nov 5, 2024

View reviewed changes

mfreed7 mentioned this pull request Nov 5, 2024

Add light dismiss functionality to <dialog> #9373

Open

chromium-wpt-export-bot mentioned this pull request Nov 5, 2024

Implement basic structure for dialog light dismiss [1/N] web-platform-tests/wpt#48976

Merged

chromium-wpt-export-bot mentioned this pull request Nov 5, 2024

Add attribute reflection behavior for dialog closedBy [2/N] web-platform-tests/wpt#48989

Merged

chromium-wpt-export-bot mentioned this pull request Nov 8, 2024

Implement dialog.requestClose() [4/N] web-platform-tests/wpt#49050

Merged

annevk reviewed Nov 8, 2024

View reviewed changes

chromium-wpt-export-bot mentioned this pull request Nov 18, 2024

Fix dialog.requestClose() in two ways web-platform-tests/wpt#49223

Merged

mfreed7 mentioned this pull request Nov 19, 2024

Close dialog elements when the open attribute is removed #10124

Open

5 tasks

css-meeting-bot mentioned this pull request Nov 20, 2024

[css-overflow-5] Disabled scroll-button state and styling w3c/csswg-drafts#11216

Open

domenic reviewed Nov 21, 2024

View reviewed changes

Address domenic@ comments

82a4561

mfreed7 commented Nov 21, 2024

View reviewed changes

annevk reviewed Nov 28, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add dialog light dismiss behavior #10737

Add dialog light dismiss behavior #10737

mfreed7 commented Oct 31, 2024 •

edited by pr-preview bot

Loading

domenic commented Nov 1, 2024

keithamus commented Nov 1, 2024

keithamus left a comment

mfreed7 commented Nov 1, 2024

annevk Nov 5, 2024

annevk Nov 5, 2024

mfreed7 Nov 8, 2024

domenic left a comment

domenic Nov 21, 2024

mfreed7 Nov 21, 2024

mfreed7 left a comment

mfreed7 Nov 21, 2024

mfreed7 commented Nov 21, 2024

domenic commented Nov 22, 2024

mfreed7 commented Nov 22, 2024

annevk Nov 28, 2024

annevk Nov 28, 2024

		[<span>CEReactions</span>] undefined <span data-x="dom-dialog-close">close</span>(optional DOMString returnValue = null);
		[<span>CEReactions</span>] undefined <span data-x="dom-dialog-request-close">requestClose</span>(optional DOMString returnValue = null);

Add dialog light dismiss behavior #10737

Are you sure you want to change the base?

Add dialog light dismiss behavior #10737

Conversation

mfreed7 commented Oct 31, 2024 • edited by pr-preview bot Loading

domenic commented Nov 1, 2024

keithamus commented Nov 1, 2024

keithamus left a comment

Choose a reason for hiding this comment

mfreed7 commented Nov 1, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

domenic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mfreed7 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mfreed7 commented Nov 21, 2024

domenic commented Nov 22, 2024

mfreed7 commented Nov 22, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mfreed7 commented Oct 31, 2024 •

edited by pr-preview bot

Loading