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 hsivo...@iki.fi 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 Fri, Aug 28, 2009 at 10:15 AM, Jeremy Orlowjor...@chromium.org 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)
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/
[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 da...@chromium.org wrote:
On Wed, Aug 26, 2009 at 1:27 AM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Aug 26, 2009 at 12:51 AM, Darin Fisher da...@chromium.orgwrote:
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.
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 jor...@chromium.org wrote:
On Wed, Aug 26, 2009 at 11:17 AM, Darin Fisher da...@chromium.org wrote:
On Wed, Aug 26, 2009 at 1:27 AM, Jeremy Orlow jor...@chromium.orgwrote:
On Wed, Aug 26, 2009 at 12:51 AM, Darin Fisher da...@chromium.orgwrote:
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
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 da...@chromium.org wrote:
On Wed, Aug 26, 2009 at 12:49 PM, Jeremy Orlow jor...@chromium.orgwrote:
On Wed, Aug 26, 2009 at 11:17 AM, Darin Fisher da...@chromium.orgwrote:
On Wed, Aug 26, 2009 at 1:27 AM, Jeremy Orlow jor...@chromium.orgwrote:
On Wed, Aug 26, 2009 at 12:51 AM, Darin Fisher da...@chromium.orgwrote:
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
