[whatwg] Proposal for non-modal versions of modal prompts

[Adam Barth]

On Mon, Mar 19, 2012 at 2:20 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 19 Mar 2012, Jochen Eisinger wrote:
>> I'd like to put forward a proposal for extending the modal prompts
>> (alert/confirm/prompt) with an optional callback parameter. If the
>> optional callback parameter is present, the javascript execution would
>> resume immediately. The callback will be invoked when the dialog that
>> doesn't need to be browser modal now, is closed.
>>
>> I wouldn't add such a callback to showModalDialog, as I think sites can
>> use e.g. window.open instead.
>>
>> I've written up the proposal here:
>> http://wiki.whatwg.org/wiki/Modal_prompts
>>
>> The motivation for this is that in a tabbed browser, modal dialogs are
>> potentially disrupting the work flow of the user as they can't interact
>> with any other web site as long as the modal dialog is displayed.
>>
>> Current browsers are having problems with the modal prompts:
>>
>> Chromium for example doesn't display a window created by showModalDialog
>> in a modal way: http://crbug.com/16045
>>
>> WebKit and Firefox don't suppress events while a modal dialog is
>> running: https://bugs.webkit.org/show_bug.cgi?id=78240 and
>> https://bugzilla.mozilla.org/show_bug.cgi?id=360872
>>
>> Firefox displays modal prompts as tab-modal. However, it's possible to
>> execute JavaScript in a tab that should be blocked by a modal prompt:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=727397 and the prompts from
>> separate tabs can block each other:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=727801
>>
>> Feedback on this proposal would be highly appreciated!
>
> Moving forward, I think the <dialog> element that we'll soon be adding is
> probably a better direction to go in.
>
> http://wiki.whatwg.org/wiki/Dialogs#Proposal

I'm not sure <dialog> addresses the same use cases as alert() and
confirm() because <dialog> is significantly more complicated.

== Non-modal confirm() ==

<script>
[...]
confirm("Are you sure you want to order the widget?", function(result) {
  if (result)
    sendOrder();
  else
    cancelOrder();
});
</script>

== <dialog> ==

<dialog id="orderConfirm">
Are you sure you want to order the widget?
<button onclick="document.getElementById('orderConfirm').close(true);">Ok</button>
<button onclick="document.getElementById('orderConfirm').close(false);">Cancel</button>
</dialog>
<script>
[...]
var dialog = document.getElementById('orderConfirm');
dialog.addEventListener('close', function() {
    if (dialog.returnValue == "true")
        sendOrder();
    else
        cancelOrder();
}, false);
dialog.showModal();
</script>

Even after all that, you get a less functional experience in some
respects.  For example, on Mac OS X, the Cancel button should be to
the left of the Ok button whereas on Windows they should be ordered as
in my example (i.e., with Ok to the left of Cancel).  I'm sure there's
some way to elaborate the sample code further to fix that bug, but I
think you get the point.

Adam