Created attachment 152338 [details] Test case illustrating confirm() not blocking new event threads Calling confirm() inside an event handler does not stop the dom from creating new, default events, while the confirm box is waiting to be dismissed. This makes it impossible to prevent those default events from triggering as the event context is lost when the thread is paused. See attached test case. Tested in Firefox 11 and WebKit r122567
I'm not seeing any difference between Safari and Firefox on this test. What should I do to observe the bug?
Of course, here are the steps for the attached test case. Steps to reproduce: 1. Open the test case file 2. Type the Enter/return key into the text field 3. Observe that a confirm dialog has been opened. Do not dismiss it. Expected: The usual Form.submit event should not be triggered. Actual: The Form.submit event is fired before the confirm() dialog box is closed. The test case calls console.error() when this happens. I hope that illustrates the difference easily enough.
What I observe in Safari is that the submit event is dispatched before keyup, which doesn't appear to be related to suspending events during a confirm(). One can check this by replacing console.log() with an alert(), making relative timing obvious.
Comment on attachment 152338 [details] Test case illustrating confirm() not blocking new event threads ><!DOCTYPE html> ><html> ><body> > <form> > <input type="text" /> > </form> > > <script> > document.getElementsByTagName('INPUT')[0].addEventListener('keydown', function(evt) { > evt.preventDefault(); > evt.stopPropagation(); > confirm('until this is dismissed, no code should run'); > }); > > document.getElementsByTagName('FORM')[0].addEventListener('submit', function(evt) { > console.error('submitted', evt); > > evt.preventDefault(); > }); > </script> ></body> ></html>
Created attachment 152432 [details] Test case with keydown event binding and expectations included.
I think that replacing the console.error with an alert makes the test invalid. It seems like the dialog stack would surpress the alert() until after the confirm is done, making things appear to work correctly. As you can see, i've attached what i hope is a better testcase, using console.group to try to illustrate the execution order a little clearer. Also keyup was the wrong event to bind earlier, it gets triggered too late. keydown is what i should've had the first time around.
I cannot get results anywhere near what's described in the new test case. I think that what you are actually seeing is that Web Inspector display is not updated while there is a confirm() on screen. In fact, this is roughly in line with the expectation of events not firing. It's not a good idea to test timing of events with a mix of console.log and alerts/confirms. > It seems like the dialog stack would surpress the alert() I don't know what dialog stack you are talking about. There is no re-ordering of alert and confirm dialogs.