Intent to implement: HTML5 <dialog> element

[Tim Nguyen]

*Summary*:
The *HTML <dialog> element* represents a dialog box or other interactive
component, such as an inspector or window.
It will initially be implemented behind a pref.

*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=840640

*Link to standard*: https://html.spec.whatwg.org/multipage/forms.html#the-
dialog-element

*Platform coverage*: All

*Estimated or target release*: Firefox 54

*Preference behind which this will be implemented*:
dom.dialog_element.enabled

*DevTools bug*: None yet, although I'm not sure how we can make DevTools
more useful here ?

*Do other browser engines implement this?*
Shipped: Chrome (since version 37)
Considering: Edge ( http://status.modern.ie/dialogelementformodals )

*Tests*:
https://github.com/w3c/web-platform-tests/blob/master/
html/dom/interfaces.html#L1835
https://github.com/w3c/web-platform-tests/tree/master/
html/semantics/interactive-elements/the-dialog-element

[Mats Palmgren]

Hi Tim, can you describe how the modality of dialog.showModal() works?
Does a web page have the power to block the user from interacting
with the entire browser (all windows)? Or is it just one window?
or just one tab? or something else?

Thanks,
Mats

[Xidorn Quan]

It just blocks the same document it is in (not even the tab if the
document is in iframe). A modal <dialog> is just another normal HTML
element with some special rendering (and focusing) rules.

- Xidorn

[Tantek Çelik]

I'm also curious how interactions between dialog.showModal() and then
controls inside of that going Fullscreen work (and then perhaps a
dialog inside that fullscreen view, etc.) Does "escape" key escape out
of one layer of dialog/fullscreen? multiple? all?

Tantek

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Astley Chen]

A simple example if you are interested in how it works on Chrome.

http://codepen.io/astleychen/pen/Obqzrr <http://codepen.io/astleychen/pen/Obqzrr>


—--
Best Regards,
Astley Chen | Mozilla Taiwan

On 21 Dec 2016, at 8:21 AM, Xidorn Quan <m...@upsuper.org> wrote:

On Wed, Dec 21, 2016, at 11:12 AM, Mats Palmgren wrote:

It just blocks the same document it is in (not even the tab if the
document is in iframe). A modal <dialog> is just another normal HTML
element with some special rendering (and focusing) rules.

- Xidorn

[Xidorn Quan]

On Wed, Dec 21, 2016, at 11:21 AM, Tantek Çelik wrote:
> I'm also curious how interactions between dialog.showModal() and then
> controls inside of that going Fullscreen work (and then perhaps a
> dialog inside that fullscreen view, etc.)

That's a... good question.

Per spec, it should just work. I mean, the document would enter
fullscreen, and dialog inside fullscreen view can be open as normal.

> Does "escape" key escape out of one layer of dialog/fullscreen? multiple? all?

I think, ideally "escape" key would exit fullscreen without touching any
modal dialog, whatever the opening order is. It is important for
security consideration, since otherwise the content may block user from
exiting fullscreen. I think implementor needs to take care of that (and
test should be added to verify this is guaranteed).

Another security concern is that this may allow websites to fool users
about what content is actually showing fullscreen. e.g. if I have
<iframe src="https://www.youtube.com/something" allowfullscreen>, when
Youtube enters fullscreen, Firefox shows a message stating that
youtube.com is in full screen, but with modal dialog, the parent
document can actually show something different on top of the iframe.

Probably this is already doable via making the iframe and its backdrop
pseudo transparent, so it may not be a new concern. Not sure how
important this issue is. I guess we should change the fullscreen warning
to always show the origin of the top browsing context rather than the
current fullscreen document.

- Xidorn

[Ben Kelly]

On Tuesday, December 20, 2016, Xidorn Quan <m...@upsuper.org> wrote:
> On Wed, Dec 21, 2016, at 11:12 AM, Mats Palmgren wrote:

> It just blocks the same document it is in (not even the tab if the
> document is in iframe). A modal <dialog> is just another normal HTML
> element with some special rendering (and focusing) rules.

So dialog.showModal() does not need to block script like other modal APIs?

Just wondering if you need something like our
nsGlobalWindow::EnterModalState(). It has some rough edges in my
experience.

[Xidorn Quan]

On Wed, Dec 21, 2016, at 12:23 PM, Ben Kelly wrote:

> On Tuesday, December 20, 2016, Xidorn Quan <m...@upsuper.org> wrote:

> > On Wed, Dec 21, 2016, at 11:12 AM, Mats Palmgren wrote:

> > It just blocks the same document it is in (not even the tab if the

> > document is in iframe). A modal <dialog> is just another normal HTML
> > element with some special rendering (and focusing) rules.

>

> So dialog.showModal() does not need to block script like other
> modal APIs?

Definitely not. I think this is designed to replace those blocking API.


- Xidorn

[Joe Hildebrand]

> On Dec 20, 2016, at 6:25 PM, Xidorn Quan <m...@upsuper.org> wrote:
>
>> So dialog.showModal() does not need to block script like other
>> modal APIs?
>
>
> Definitely not. I think this is designed to replace those blocking API.

Why doesn't showModal() return a Promise?

--
Joe Hildebrand

[Xidorn Quan]

This is a question for the spec. I guess it theoretically can return a
Promise, though I suspect that there might be some weird corner cases
which is hard to handle.

Anyway, I don't think dev-platform is the right place for this kind of
spec issues. You can raise an issue to HTML spec to start the discussion
there.

- Xidorn

[Boris Zbarsky]

On 12/21/16 4:13 PM, Xidorn Quan wrote:
> This is a question for the spec. I guess it theoretically can return a
> Promise, though I suspect that there might be some weird corner cases
> which is hard to handle.

Note that I expect that this spec was written before Promise was a
thing. The setup where we return a value in an attribute of the element
(!) is pretty bizarre...

> Anyway, I don't think dev-platform is the right place for this kind of
> spec issues. You can raise an issue to HTML spec to start the discussion
> there.

Sure, but it bears on whether we want to ship the spec in its current state.

-Boris

[Justin Dolske]

What's the expected experience if chrome code uses this feature? (In a
chrome window, interaction with a content window isn't the thing I'm
wondering about.)

Justin

[Tim Nguyen]

Non-modal dialogs should just work fine in a chrome window (the dialog
would just be like a centered absolute positioned div). As for modal
dialogs (eg. dialogs that makes everything else inert), it would depend on
whether the current top-layer implementation works within a chrome window
and I don't think it is the case currently. So, I don't expect modal
dialogs to work within the chrome window (at least not without some extra
platform work). Xidorn might know better though.

As for how modal dialogs *should* behave in a chrome window, I would expect
it to be the same as for web content, i.e. it modal dialogs should make all
UI elements except the current dialog inert.

Tim

On Fri, Dec 23, 2016 at 12:33 AM, Justin Dolske <dol...@mozilla.com> wrote:

> What's the expected experience if chrome code uses this feature? (In a
> chrome window, interaction with a content window isn't the thing I'm
> wondering about.)
>
> Justin
>
> On Tue, Dec 20, 2016 at 3:56 PM, Tim Nguyen <nti...@gmail.com> wrote:
>
>> *Summary*:
>> The *HTML <dialog> element* represents a dialog box or other interactive
>> component, such as an inspector or window.
>> It will initially be implemented behind a pref.
>>
>> *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=840640
>>
>> *Link to standard*: https://html.spec.whatwg.org/m
>> ultipage/forms.html#the-
>> dialog-element

>> <https://html.spec.whatwg.org/multipage/forms.html#the-dialog-element>

[Martin Thomson]

On Fri, Dec 23, 2016 at 7:14 AM, Boris Zbarsky <bzba...@mit.edu> wrote:
> Note that I expect that this spec was written before Promise was a thing.
> The setup where we return a value in an attribute of the element (!) is
> pretty bizarre...

Is this irredeemable? I mean, the attribute is probably a lost cause,
but a void function can usually be safely transformed into a
Promise-bearing one.

[Boris Zbarsky]

On 12/22/16 10:03 PM, Martin Thomson wrote:
> On Fri, Dec 23, 2016 at 7:14 AM, Boris Zbarsky <bzba...@mit.edu> wrote:
>> Note that I expect that this spec was written before Promise was a thing.
>> The setup where we return a value in an attribute of the element (!) is
>> pretty bizarre...
>
> Is this irredeemable?

Probably not.

> I mean, the attribute is probably a lost cause

Why? Is there significant usage, or at least wide implementation, of
that part of the API already? The original intent said that only Chrome
is shipping this.

> but a void function can usually be safely transformed into a
> Promise-bearing one.

Indeed.

-Boris

[Martin Thomson]

On Fri, Dec 23, 2016 at 6:20 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
>> I mean, the attribute is probably a lost cause
>
> Why? Is there significant usage, or at least wide implementation, of that
> part of the API already? The original intent said that only Chrome is
> shipping this.

Fair point. I guess the question becomes whether Chrome compatibility
is the reason we are doing this.

[Xidorn Quan]

On Fri, Dec 23, 2016, at 02:33 PM, Tim Nguyen wrote:
> Non-modal dialogs should just work fine in a chrome window (the dialog
> would just be like a centered absolute positioned div). As for modal
> dialogs (eg. dialogs that makes everything else inert), it would depend
> on
> whether the current top-layer implementation works within a chrome window
> and I don't think it is the case currently. So, I don't expect modal
> dialogs to work within the chrome window (at least not without some extra
> platform work). Xidorn might know better though.

I think top layer should work for chrome document. In the frame tree
(rendering tree), top layer elements are direct children of the viewport
frame (which is the root of frame tree in all kinds of documents). So I
don't expect much extra work (if any) for supporting modal dialogs in
chrome document on top of the support in web content.

- Xidorn

[Tantek Çelik]

On Fri, Dec 23, 2016 at 4:02 PM, Martin Thomson <m...@mozilla.com> wrote:
> On Fri, Dec 23, 2016 at 6:20 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

>>> I mean, the attribute is probably a lost cause
>>
>> Why? Is there significant usage, or at least wide implementation, of that
>> part of the API already? The original intent said that only Chrome is
>> shipping this.
>

> Fair point. I guess the question becomes whether Chrome compatibility
> is the reason we are doing this.

Yes this is the key question.

IF there is a webcompat issue now, THEN we have little choice but to
implement the API as is.

IF there is no webcompat issue, THEN
* We should NOT implement this "legacy" API, as us implementing in
addition to Chrome may be enough to create a compat issue (for
everyone else for this API design, and provide another point of
inconsistency for web developers). Let's avoid a platform wart if we
can.
* We should be prepared to propose fixes/updates to the API that use a
Promise per points from Joe, mt, bz, and then prototype/implement
accordingly.


Is there some other time pressure / use-case need to ship this feature
"soon" that hasn't been discussed in this thread so far?

Thanks,

Tantek