Bug 84635 (dialog-element)

Summary: Implement the dialog element
Product: WebKit Reporter: Dominic Cooney <dominicc>
Component: DOMAssignee: Tim Nguyen (:ntim) <ntim>
Status: RESOLVED FIXED    
Severity: Normal CC: abarth, ap, bugzilla, cigitia, claude.pache, code.vineet, craig+webkit, dmh, dpaddock, dvpdiner2, ebrahim, eoconnor, ericbidelman, falken, fede_navarrete, fishd, fred.wang, fweber, ian, jamesdavidmorris, jcraig, jond, kai.hollberg, koivisto, matiasnu, me, mike, mtchllvn, ntim, owp-launch-tracking, peter, pimvdb, priyajeet.hora, sander, simon.fraser, stephen.cunliffe, syoichi, vertigoback, webkit-bug-importer, webkit, yljia
Priority: P2 Keywords: InRadar, WebExposed
Version: WebKit Nightly Build   
Hardware: All   
OS: All   
URL: https://html.spec.whatwg.org/multipage/forms.html#the-dialog-element
See Also: https://bugs.webkit.org/show_bug.cgi?id=151885
https://bugs.webkit.org/show_bug.cgi?id=199839
Bug 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    
Bug Blocks: 159753    

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
<rdar://problem/11798655>
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.

https://html.spec.whatwg.org/multipage/interaction.html#focus-fixup-rule-three
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.