84635 dialog-element 2012-04-23 14:37:12 -0700 Implement the dialog element 2025-04-03 15:11:24 -0700 1 1 1 Unclassified WebKit DOM WebKit Nightly Build All All RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=151885 https://bugs.webkit.org/show_bug.cgi?id=199839 https://html.spec.whatwg.org/multipage/forms.html#the-dialog-element InRadar, WebExposed P2 Normal --- 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 159753 1 dominicc ntim abarth ap bugzilla cigitia claude.pache code.vineet craig+webkit ddkilzer dmh dpaddock dvpdiner2 ebrahim eoconnor ericbidelman falken fede_navarrete fishd fred.wang fweber ian jamesdavidmorris jamie.r.herrera 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 oldest_to_newest 608025 0 dominicc 2012-04-23 14:37:12 -0700 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. 608351 1 fishd 2012-04-23 21:20:05 -0700 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. 609221 2 eoconnor 2012-04-24 16:21:18 -0700 https://bugs.webkit.org/show_bug.cgi?id=84796 tracks the implementation of the new stacking layer that the <dialog> element depends on. 662335 3 webkit-bug-importer 2012-07-03 10:24:46 -0700 <rdar://problem/11798655> 922631 4 koivisto 2013-08-29 13:21:15 -0700 The current implementation was removed in http://trac.webkit.org/changeset/154835 1160712 5 falken 2016-01-31 18:12:57 -0800 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. 1177737 6 jcraig 2016-03-24 11:56:46 -0700 *** Bug 112753 has been marked as a duplicate of this bug. *** 1177739 7 jcraig 2016-03-24 12:00:48 -0700 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 1258009 8 jcraig 2016-12-08 18:59:41 -0800 See also @inert in bug 165279 1712707 9 olestr 2020-12-08 01:27:08 -0800 https://webkit.org/status/#feature-dialog-element 1712711 10 olestr 2020-12-08 01:44:07 -0800 (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. 1715081 11 steffen.weber 2020-12-16 05:25:53 -0800 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 1715141 12 simon.fraser 2020-12-16 09:41:55 -0800 No; the implementation hasn't really started. 1759057 13 fede_navarrete 2021-05-11 14:22:22 -0700 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? 1773094 14 dmh 2021-06-28 09:28:05 -0700 (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 1794575 15 jamesdavidmorris 2021-09-17 13:15:56 -0700 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?) 1829934 16 dmh 2022-01-11 15:14:45 -0800 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. 2108535 17 jamie.r.herrera 2025-04-03 10:02:29 -0700 Any updates on Safari? 2108626 18 ddkilzer 2025-04-03 15:11:24 -0700 This particular issue is considered resolved as of 2022. If there are any remaining issues, please file new bug reports and relate them to this bug. Thanks!