Bug 84635 (dialog-element) - Implement the dialog element
Summary: Implement the dialog element
Alias: dialog-element
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: WebKit Nightly Build
Hardware: All All
: P2 Normal
Assignee: Tim Nguyen (:ntim)
URL: https://html.spec.whatwg.org/multipag...
Keywords: InRadar, WebExposed
: 112753 (view as bug list)
Depends on: 236322 84796 90521 90670 90931 90934 95946 103719 110952 112085 113273 205542 205543 226169 226172 226175 227493 227523 227534 227537 227566 227800 227801 227802 227872 227907 227915 227986 228822 228845 229042 229093 229297 229315 229317 229318 229330 229488 229728 229815 230008 230229 230230 230474 230678 230680 230681 230686 230690 230845 231290 231292 231307 231392 231721 231722 231736 231741 231832 232784 232911 232926 233072 233099 233320 233482 233514 233525 234170 234442 234479 234980 234984 235194 235369 235836 236274 237054 238425 240109
Blocks: 159753
  Show dependency treegraph
Reported: 2012-04-23 14:37 PDT by Dominic Cooney
Modified: 2022-07-24 12:23 PDT (History)
41 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Dominic Cooney 2012-04-23 14:37:12 PDT
This is part of the HTML5 spec: <http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#the-dialog-element>

This manages a stack of dialogs and should let pages show “page modal” UI without resorting to modal dialogs (alert, confirm, prompt) and without the difficulty of managing pop-up windows or in-page divs.
Comment 1 Darin Fisher (:fishd, Google) 2012-04-23 21:20:05 PDT
Implementation note:  We should make sure that windowed plugins cannot sit on top of a rendered dialog.  Windowed plugins by default cover the rendered page as they are implemented using a native window (e.g., HWND).  To give the illusion of the page being on top, it is necessary to cut-out part of the native window (e.g., using SetWindowRgn).  We already have machinery in WebKit for this as you can position an IFRAME above an EMBED (using CSS Z-index) to cause the IFRAME to occlude the EMBED.  See the getPluginOcclusions function defined in IFrameShimSupport.cpp.  That file would probably need to be renamed.
Comment 2 Theresa O'Connor 2012-04-24 16:21:18 PDT
https://bugs.webkit.org/show_bug.cgi?id=84796 tracks the implementation of the new stacking layer that the <dialog> element depends on.
Comment 3 Radar WebKit Bug Importer 2012-07-03 10:24:46 PDT
Comment 4 Antti Koivisto 2013-08-29 13:21:15 PDT
The current implementation was removed in http://trac.webkit.org/changeset/154835
Comment 5 Matt Falkenhagen 2016-01-31 18:12:57 PST
FWIW this element was implemented in Chromium <https://www.chromestatus.com/feature/5770237022568448>, but I'm not actively working on it for WebKit. So, I'll unassign myself.
Comment 6 James Craig 2016-03-24 11:56:46 PDT
*** Bug 112753 has been marked as a duplicate of this bug. ***
Comment 7 James Craig 2016-03-24 12:00:48 PDT
Focus keyboard behavior seems reasonably specified, though Chrome's implementation does not yet support it. We'd need the "Focus Fix-up" rule for FKA and AX.

Comment 8 James Craig 2016-12-08 18:59:41 PST
See also @inert in bug 165279
Comment 10 Ole Strøm 2020-12-08 01:44:07 PST
(In reply to Ole Strøm from comment #9)
> https://webkit.org/status/#feature-dialog-element

Woops. Still figuring Bugzilla out.

What I meant to say, was that I've sneakily added Jon Davis to the CC list, in hopes that he might see this, and that he might give us a status on this.

Is this still the main entry/bug for https://webkit.org/status/#feature-dialog-element? Is it actually still "Under Consideration"?

I'd really love to see this added, especially since it seems Firefox's implementation is nearing public release.

Then it would be just Safari holding us back: https://caniuse.com/dialog
Which I find strange, seeing it would be a huge win for accessibility.

And Apple have a really good track record for accessibility. I'm in AWE each time I see some of the clips in the promos, showcasing that anyone can do advanced stuff, like editing a video!

Stuff like that inspires me to push accessibility hard on the web stuff I create.

Which is why you're reading this. This dialog element would be a huge win for accessibility, and the need for dialogues is prevalent on the web, especially modern web applications.

I'd love some inputs and thoughts on all of this.
Especially if I just should go ahead and use https://github.com/GoogleChrome/dialog-polyfill until it's no longer needed, or if there are some better alternatives.
Comment 11 Steffen Weber 2020-12-16 05:25:53 PST
The experimental feature "Dialog Element" in Safari 14 doesn't fire "close" events when closing a dialog. Should I file a separate issue for this?

See https://github.com/GoogleChrome/dialog-polyfill/issues/211
Comment 12 Simon Fraser (smfr) 2020-12-16 09:41:55 PST
No; the implementation hasn't really started.
Comment 13 Federico 2021-05-11 14:22:22 PDT
I'm wondering why this has not been implemented. It has been almost a decade since it was requested. I could understand the other topics about privacy but this seems to be basic at this point in time. Any plans if it's going to be released during this year or the next one?
Comment 14 dmh 2021-06-28 09:28:05 PDT
(In reply to Federico from comment #13)
> I'm wondering why this has not been implemented. It has been almost a decade
> since it was requested. I could understand the other topics about privacy
> but this seems to be basic at this point in time. Any plans if it's going to
> be released during this year or the next one?
There is currently an unresolved issue in the specification, relating to which element should gain focus. This is why there hasn't been a release yet in Firefox. I don't know if this has slowed Webkit progress, but I imagine a Firefox release would renew interest here. Related links:

  * https://github.com/whatwg/html/issues/1929
  * https://github.com/whatwg/html/pull/4184
  * https://bugzilla.mozilla.org/show_bug.cgi?id=840640
Comment 15 James Morris 2021-09-17 13:15:56 PDT
I have designed many Single Page Applications, and with Edge being on Chromium, the dialog element is THE main thing that makes a small simple application framework not be able to be created. Ie, the dialog polyfill is more code than the entire routing/page display mechanism.  

Surly a question of 'which element gets focused' can be resolved (after 10 years?)
Comment 16 dmh 2022-01-11 15:14:45 PST
Mozilla are aiming to ship <dialog> support in Firefox 98.

Note that the issue of which element should receive focus has *not* been resolved. However, Firefox compatibility reports (due to lack of <dialog>) suggest it would be better to ship now and potentially amend behaviour later. It's also observed that the accessibility of hand-rolled dialogs is usually worse than <dialog>, so releasing now would be an improvement.