Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 840640 - Implement the HTML5 dialog element
: Implement the HTML5 dialog element
Status: NEW
: dev-doc-needed, DevAdvocacy, html5
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: All All
: -- normal with 67 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Jet Villegas (:jet)
Depends on: ::backdrop 1236828
Blocks: html5 html5test 981796 1230801
  Show dependency treegraph
Reported: 2013-02-12 11:42 PST by Dave Hodder
Modified: 2016-09-22 22:50 PDT (History)
66 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

HTML testcase (4.86 KB, text/html)
2013-03-02 03:52 PST, Dave Hodder
no flags Details

Description Dave Hodder 2013-02-12 11:42:20 PST
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:18.0) Gecko/20100101 Firefox/18.0
Build ID: 20130201065344

Steps to reproduce:

Please add support for the dialog element, which makes it easier to develop stackable dialog boxes and pop-up UI components within an HTML document.

(Work to support <dialog> and its associated API within WebKit began in 2012, but is not yet complete.)
Comment 1 :Ms2ger (⌚ UTC+1/+2) 2013-02-12 11:53:17 PST
Sounds like something humph would be interested in :)
Comment 2 Dave Hodder 2013-03-02 03:52:24 PST
Created attachment 720266 [details]
HTML testcase
Comment 3 Peter Gasston 2013-09-27 06:28:26 PDT
There is an implementation of this in the latest builds of Chrome Canary (32.0.1653.0) and a demo and polyfill here:
Comment 4 Matt Falkenhagen 2013-12-10 18:29:03 PST
Hi all. I've been working on implementing <dialog> in Chrome behind a flag and am thinking of exposing it by default soon. I'm curious about whether Mozilla folks feel positively about this feature and the current spec, or if anyone feels shipping is a bad idea?

Comment 5 Marc Nieper-Wißkirchen 2014-05-26 04:54:04 PDT
Implementing the dialog element makes sense in my opinion because it is hard to polyfill correctly. Modal dialogs have to render all nodes but themselves (and descendants) inert. However, without implementing showModal, one cannot make nodes inert by script.

Workarounds are to listen for focus changes and setting the focus back onto the dialog whenever it leaves and to prevent further events from happening outside the dialog by putting a backdrop between the dialog and the rest of the document. Finally, one usually adds aria-hidden="true" onto the non-dialog part of the document.

This raises a number of problems, though: 1) There might be another way to access the document that is not fully inert than by just preventing mouse and keyboard events and controlling the focus. 2) The dialog element cannot be a descendant of anything that has to be made inaccessible (due to the way aria-hidden works). 3) Trapping the focus inside the dialog means that one cannot access the location bar with the tab key without closing the dialog first.
Comment 6 Dave Hodder 2014-09-24 12:20:45 PDT
Chrome and Opera now have mostly complete support, including support for <form method="dialog">. They omit support for specifying an optional anchor point argument on .show() and .showModal().

There is MDN reference documentation at and
Comment 7 Marco Zehe (:MarcoZ) 2014-11-27 08:12:16 PST
This would be very useful to have for accessibility, too. It would mittigat e the need for web authors to create their own dialog widgets and have to use hacks like aria-hidden to hide everything *outside* the dialog widget from assistive technologies for people with disabilities. It is a real nuisance to deal with from both an evangelism and technical standpoint, and having the native html:dialog element implemented would hugely improve the lives of many many people.
Comment 8 jlregeim 2015-05-04 14:23:57 PDT
With the planned removal of showModalDialog, this feature should get implemented rather than forcing applications to polyfill dialog functionality.  See for more on the removal of showModalDialog.
Comment 9 jgw9617 2015-10-20 11:30:05 PDT Comment hidden (me-too)
Comment 10 jgw9617 2015-10-20 11:30:56 PDT
Also, native dialogs would be even more useful on FirefoxOS
Comment 11 Potch [:potch] 2016-06-21 17:47:15 PDT
Seeing interest in this spike again recently, tracking this with DevAdvocacy.
Comment 12 Xidorn Quan [:xidorn] (UTC+10) 2016-06-21 17:57:01 PDT
Probably someone could take this and implement functions other than dialog.showModal().

To implement dialog.showModal() correctly, we need to convert our fullscreen stack into top layer stack, and handle both fullscreen and modal dialog there. To having the fully-implemented top layer stack, we may need to finish bug 1195213 first. And I don't think other parts of <dialog> should be blocked by that.

Note You need to log in before you can comment on or make changes to this bug.