Bug 84635 - Implement the DIALOG element
: Implement the DIALOG element
Status: NEW
Product: WebKit
Classification: Unclassified
Component: HTML DOM
: WebKit Nightly Build
: All All
: P2 Normal
Assigned To: Nobody
https://html.spec.whatwg.org/multipag...
: InRadar, WebExposed
Depends on: 84796 95946 103719 90521 90670 90931 90934 110952 112085 113273
Blocks: 151885
  Show dependency treegraph
 
Reported: 2012-04-23 14:37 PDT by Dominic Cooney
Modified: 2016-06-25 15:43 PDT (History)
20 users (show)

See Also:


Attachments

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 Edward 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