Re: [whatwg] Run to completion in the face of modal dialog boxes (WAS: Storage mutex)
On Fri, Aug 28, 2009 at 10:15 AM, Jeremy Orlow wrote: > Can anyone from Firefox speak to whether this should be considered a bug > (I'm happy to file) or whether this behavior is intended? I'd say it's a bug. However I'm not sure that fixing it is high priority. At least not until we've made architectural changes that allow us to fix it in a satisfactory way. / Jonas
Re: [whatwg] Run to completion in the face of modal dialog boxes (WAS: Storage mutex)
Can anyone from Firefox speak to whether this should be considered a bug (I'm happy to file) or whether this behavior is intended? On Thu, Aug 27, 2009 at 3:39 AM, Henri Sivonen wrote: > On Aug 26, 2009, at 22:54, Darin Fisher wrote: > > Firefox and IE implement window modal, which is clearly buggy, but of >> course the world hasn't imploded. >> > > > FWIW, Firefox differs here on Windows and Mac. On Windows, you can close > tabs in the window even when window.alert() is up, which may lead to > "interesting" effects. > > -- > Henri Sivonen > hsivo...@iki.fi > http://hsivonen.iki.fi/ > > >
Re: [whatwg] Run to completion in the face of modal dialog boxes (WAS: Storage mutex)
On Aug 26, 2009, at 22:54, Darin Fisher wrote: Firefox and IE implement window modal, which is clearly buggy, but of course the world hasn't imploded. FWIW, Firefox differs here on Windows and Mac. On Windows, you can close tabs in the window even when window.alert() is up, which may lead to "interesting" effects. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Run to completion in the face of modal dialog boxes (WAS: Storage mutex)
On Wed, Aug 26, 2009 at 12:54 PM, Darin Fisher wrote:
> On Wed, Aug 26, 2009 at 12:49 PM, Jeremy Orlow wrote:
>
>> On Wed, Aug 26, 2009 at 11:17 AM, Darin Fisher wrote:
>>
>>> On Wed, Aug 26, 2009 at 1:27 AM, Jeremy Orlow wrote:
>>>
On Wed, Aug 26, 2009 at 12:51 AM, Darin Fisher wrote:
> On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan <
> rob...@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.
>>
>
> Chrome and Safari both implement app-modal alerts. Firefox and IE
> implement window modal, which is clearly buggy, but of course the world
> hasn't imploded. I haven't tested Opera.
>
> Personally, I would like to change Chrome to not put up app modal alerts.
> I think it is bad UI, but I'm not sure how to do so without also breaking
> the contract that JavaScript execution appear single threaded.
>
> -Darin
>
Also, just for completeness, if you consider scoping an alert to a window,
then what happens when an alert is generated by another window? If each
alert is implemented using a nested event loop, then closing the first alert
will not return execution control back to the page that call alert.
So, the user will be left with a dead browser window. This is very similar
to the problem that exists with app modal alerts where one window is
inactive while another is showing an alert.
Without something like co-routines, I'm not sure how to solve this.
-Darin
Re: [whatwg] Run to completion in the face of modal dialog boxes (WAS: Storage mutex)
On Wed, Aug 26, 2009 at 12:49 PM, Jeremy Orlow wrote:
> On Wed, Aug 26, 2009 at 11:17 AM, Darin Fisher wrote:
>
>> On Wed, Aug 26, 2009 at 1:27 AM, Jeremy Orlow wrote:
>>
>>> On Wed, Aug 26, 2009 at 12:51 AM, Darin Fisher wrote:
>>>
On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan <
rob...@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.
>
Chrome and Safari both implement app-modal alerts. Firefox and IE implement
window modal, which is clearly buggy, but of course the world hasn't
imploded. I haven't tested Opera.
Personally, I would like to change Chrome to not put up app modal alerts. I
think it is bad UI, but I'm not sure how to do so without also breaking the
contract that JavaScript execution appear single threaded.
-Darin
[whatwg] Run to completion in the face of modal dialog boxes (WAS: Storage mutex)
On Wed, Aug 26, 2009 at 11:17 AM, Darin Fisher wrote:
> On Wed, Aug 26, 2009 at 1:27 AM, Jeremy Orlow wrote:
>
>> On Wed, Aug 26, 2009 at 12:51 AM, Darin Fisher wrote:
>>
>>> On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan <
>>> rob...@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.
