Skip to content
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

dispatch toggleevents for dialog open/close #10091

Open
wants to merge 12 commits into
base: main
Choose a base branch
from

Conversation

keithamus
Copy link
Contributor

@keithamus keithamus commented Jan 25, 2024

This attempts to fix #9733 by specifying that:

  • a Dialog's show() steps should dispatch a beforetoggle cancellable event
  • followed by a queuing a non-cancellable toggle event.
  • a Dialog's showModal() steps should dispatch a beforetoggle cancellable event
  • followed by a queuing non-cancellable toggle event.
  • the close the dialog steps should disaptch a non-cancellable beforetoggle event
  • followed by queuing a non-cancellable toggle event.

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


/interactive-elements.html ( diff )

@josepharhar
Copy link
Contributor

I think this needs the "toggle task tracker" concept used in details elements in order to coalesce async toggle events: https://html.spec.whatwg.org/multipage/interactive-elements.html#queue-a-details-toggle-event-task

If you do this and open+close the dialog element synchronously , there should be one "toggle" event with both oldState and newState set to "closed":

dialog.showModal();
dialog.close();

@josepharhar
Copy link
Contributor

Consider chrome as tentatively interested. I will file an intent to ship to get an official position when this gets a bit more attention from the other browsers, but I don't anticipate objections

@smaug----
Copy link

Also Gecko is interested assuming the pr follows what was discussed at TPAC.

@josepharhar
Copy link
Contributor

Tests can be added to the OP: web-platform-tests/wpt#44208

@keithamus keithamus marked this pull request as ready for review February 8, 2024 21:31
@marco-prontera
Copy link

Hi, this implementation could help us improve a popup, such as a CMP, for better integration by utilizing native browser APIs, specifically the Popover API, to make everything more robust. This will enable us to further improve the INP impact, as described in my case study here: https://web.dev/case-studies/pubconsent-inp?hl=en. Since the CMP is a predominant component on the web, I believe this kind of implementation should be supported as much as possible. I hope it helps. Thank you

@keithamus
Copy link
Contributor Author

@annevk would you have time to review this or otherwise delegate it out to another editor for review?

Copy link
Member

@annevk annevk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe @nt1m or @josepharhar is interested in reviewing this?

Comment on lines +61002 to +61005
<li><p>Set <var>element</var>'s <span>dialog toggle task tracker</span> to a struct with <span
data-x="toggle-task-task">task</span> set to the just-queued <span
data-x="concept-task">task</span> and <span data-x="toggle-task-old-state">old state</span> set
to <var>oldState</var>.</p></li>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just-queued is a lil vague. But I guess we have no alternative?

Copy link
Contributor Author

@keithamus keithamus Oct 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I cribbed this from the popover part of the spec which does the same thing. Happy to look at alternatives.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah if all the task queueing algorithms returned the task they create then this would be better. Maybe that could be done as a follow up and we could fix up this part and the identical popover one?

source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
moz-wptsync-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Oct 14, 2024
whatwg/html#10091

This also slightly refactors FireToggleEvent to allow to to
accomodate both popovers and now also dialogs

Differential Revision: https://phabricator.services.mozilla.com/D225449

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1876762
gecko-commit: a8b51403fa4f1dd6d936826f2a5b14c670426f3d
gecko-reviewers: smaug
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request Oct 15, 2024
…e r=smaug

whatwg/html#10091

This also slightly refactors FireToggleEvent to allow to to
accomodate both popovers and now also dialogs

Differential Revision: https://phabricator.services.mozilla.com/D225449
moz-wptsync-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Oct 15, 2024
whatwg/html#10091

This also slightly refactors FireToggleEvent to allow to to
accomodate both popovers and now also dialogs

Differential Revision: https://phabricator.services.mozilla.com/D225449

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1876762
gecko-commit: a8b51403fa4f1dd6d936826f2a5b14c670426f3d
gecko-reviewers: smaug
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this pull request Oct 15, 2024
…e r=smaug

whatwg/html#10091

This also slightly refactors FireToggleEvent to allow to to
accomodate both popovers and now also dialogs

Differential Revision: https://phabricator.services.mozilla.com/D225449

UltraBlame original commit: a8b51403fa4f1dd6d936826f2a5b14c670426f3d
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this pull request Oct 15, 2024
…e r=smaug

whatwg/html#10091

This also slightly refactors FireToggleEvent to allow to to
accomodate both popovers and now also dialogs

Differential Revision: https://phabricator.services.mozilla.com/D225449

UltraBlame original commit: a8b51403fa4f1dd6d936826f2a5b14c670426f3d
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this pull request Oct 15, 2024
…e r=smaug

whatwg/html#10091

This also slightly refactors FireToggleEvent to allow to to
accomodate both popovers and now also dialogs

Differential Revision: https://phabricator.services.mozilla.com/D225449

UltraBlame original commit: a8b51403fa4f1dd6d936826f2a5b14c670426f3d
@@ -61030,6 +61101,7 @@ interface <dfn interface>HTMLDialogElement</dfn> : <span>HTMLElement</span> {
document</span>.</p></li>

<li><p>Run the <span>dialog focusing steps</span> given <span>this</span>.</p></li>

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove this newline?

@josepharhar
Copy link
Contributor

lgtm, I don't see any differences between this spec and the chromium implementation

i3roly pushed a commit to i3roly/firefox-dynasty that referenced this pull request Oct 16, 2024
…e r=smaug

whatwg/html#10091

This also slightly refactors FireToggleEvent to allow to to
accomodate both popovers and now also dialogs

Differential Revision: https://phabricator.services.mozilla.com/D225449
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Add ToggleEvents to <dialog>.showModal()
5 participants