|Summary:||Implement the DIALOG element|
|Product:||WebKit||Reporter:||Dominic Cooney <dominicc>|
|Severity:||Normal||CC:||abarth, ap, bugzilla, cigitia, claude.pache, code.vineet, dvpdiner2, ebrahim, eoconnor, ericbidelman, falken, fishd, futwick, ian, jcraig, kai.hollberg, koivisto, matiasnu, mike, mtchllvn, owp-launch-tracking, paulirish, peter, pimvdb, priyajeet.hora, sander, stephen.cunliffe, syoichi, webkit-bug-importer, webkit, yljia|
|Version:||WebKit Nightly Build|
|Bug Depends on:||84796, 95946, 103719, 90521, 90670, 90931, 90934, 110952, 112085, 113273|
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 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