[whatwg] Run to completion in the face of modal dialog boxes (WAS: Storage mutex)

[Jeremy Orlow]

On Wed, Aug 26, 2009 at 11:17 AM, Darin Fisher <darin at chromium.org> wrote:

> On Wed, Aug 26, 2009 at 1:27 AM, Jeremy Orlow <jorlow at chromium.org> wrote:
>
>> On Wed, Aug 26, 2009 at 12:51 AM, Darin Fisher <darin at chromium.org>wrote:
>>
>>>  On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan <
>>> robert at ocallahan.org> wrote:
>>>
>>>> That behaviour sounds worse than what Firefox currently does, where an
>>>> alert disables input to all tabs in the window (which is already pretty
>>>> bad), because it willl make applications in visually unrelated tabs and
>>>> windows hang.
>>>>
>>>
>>> You can have script connections that span multiple tabs in multiple
>>> windows, so in order to preserve the run-to-completion semantics of
>>> JavaScript, it is important that
>>> window.{alert,confirm,prompt,showModalDialog} be modal across all windows in
>>> the browser.  This is why those APIs suck rocks, and we should never create
>>> APIs like them again.
>>>
>>
>> I don't understand your point here.  Are you saying that the current
>> firefox behavior is not correct, that releasing the storage lock on these
>> events is not correct, or something else?
>>
>
> I meant that the current Firefox behavior is technically incorrect.  No one
> likes app modal dialogs, but how else can you guarantee run-to-completion
> semantics? How else do you prevent other scripts from modifying your state
> while you are stuck calling into window.alert().
>

I don't know much about this issue, but it seems like something that should
either be fixed in Firefox (and other browsers?) or changed in the spec.
 I'm interested to hear if others have thoughts on it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090826/600ea8ed/attachment.htm>