Closed
Bug 60150
Opened 24 years ago
Closed 18 years ago
Modal dialogs (alert, confirm, prompt) do not halt code execution of all other scripts on that page
Categories
(Core :: DOM: Core & HTML, defect, P3)
Tracking
()
Future
People
(Reporter: tom, Unassigned)
References
(Blocks 1 open bug, )
Details
(4 keywords, Whiteboard: [T2])
Attachments
(3 files)
screenshot
Description: Modal dialogs (alert, confirm, prompt), do not halt all code
execution when called.
Reproducible: always.
This has never been done by (I believe) all other browsers that have supported
them. This might be a problem if, say - user input was required to be set to a
variable in one event, and retrived in another. If the 2nd event fired before
the user had finished inputted the information, then it could not retrive it.
Also, it means you can popup more than one modal dialog - which is not the
point of them.
See URL for example.
|
||
Comment 1•24 years ago
|
||
COnfirming since I can reproduce the bug with the test case. However, I am not
sure we want to stop ALL code from running as soon as a modal window pops up.
For example if we're loading a url and we open a dialog, should it stop the url
from loading? Not sure... See also bug 22049.
Fabian.
Status: UNCONFIRMED → NEW
Ever confirmed: true
|
Reporter | |
Comment 2•24 years ago
|
||
Sorry, I meant all other scripts on that page - not all browser code.
|
||
Comment 3•24 years ago
|
||
This is probably a dupe of one of danm's modality bugs, reassigning.
Assignee: jst → danm
testcase source:
<html><head><title>Modal Dialog Testcase</title></head>
<body><form>
<input type="button" value="Click me to Show Alerts"
onMouseDown="alert('I have been fired onMouseDown')"
onClick="alert('I have been fired onClick')">
</form></body>
Aren't modal dialogs fun?
This is a new twist on this problem, as far as I know. The OS mousedown event
triggers the onMouseDown event handler, which spawns a modal window. As soon as
that's up and running, processing OS events, the OS mouseup event going to the
same <input> button triggers the onClick event handler, which spawns a second
modal window.
Note this is identical to bug 60280.
Status: NEW → ASSIGNED
|
||
Comment 5•24 years ago
|
||
So the second (click, occasioned by mouseup) event should not be handled by the
nested (modal) event loop. For one thing, it's bound for another window than
the modal one. Does that suggest an easy fix (queue it in the lower -- not top
of stack -- event queue)?
/be
Not to forget we're talking about two of Mozilla's three (by my count) event
systems. The problem here is caused by native events, which are independent of
NSPR events; the ones which come in stackable queues.
On all platforms, we have some sort of mechanism that supresses delivery or
processing of native events to at least the parent window when a modal one is up.
But in all cases the follow-on mouse events sneak through during the slack time
when the first event is being processed, JS interpretation is invoked, and a
modal window eventually results.
I think I just need to subvert native event delivery a little earlier in the
process. I won't be able to use the current mechanism (because it kicks in as
early as it can, and apparently that's not early enough); I'll have to graft on a
second one. Luckily, on at least Windows and Linux, the problematic follow-on
events aren't processed until the modal window event loop is up, so in theory I
have a convenient place to do this. (On the Mac, I'm not sure, because the
Metrowerks Heisenberg debugger seems to influence timing enough to prevent the
second alert from coming up at all.)
But anyway, you (and equivalent bug 60280) answered my question. This wants to
be fixed by native event munging, not by JS lockout.
|
||
Comment 8•24 years ago
|
||
Bug 65943 might be related. (Button that creates an alert doesn't seem to
un-depress until you mouseover the alert.)
|
||
Comment 9•23 years ago
|
||
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1
(you can query for this string to delete spam or retrieve the list of bugs I've
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
|
||
Comment 10•23 years ago
|
||
*** Bug 57231 has been marked as a duplicate of this bug. ***
|
|
||
Comment 11•23 years ago
|
||
nsbeta1+ per ADT/Embed triage. Caused a crash in bug 57231, which was marked as
a dupe of this bug.
|
||
Comment 12•23 years ago
|
||
Tested using the following:
3_22_05 netscape trunk
3_22_11 mfcembed trunk
3_22_11 mfcembed 0.9.9 branch
using the code mentioned in #4 (see attached testcase) with the following results:
3_22_05 netscape trunk:
Clicking on the button generates 'I have been fired onclick'. Click 'ok' - the
next alert is generated 'I have been fired on mouse down'.
3_22_11 mfcembed trunk and 0.9.9. branch:
Clicking on the button generates 'I have been fired on mouse down'. Click 'ok' -
no further alert is generated and button has focus
|
|
||
Comment 13•23 years ago
|
||
|
||
Updated•23 years ago
|
|
||
Comment 14•22 years ago
|
||
Setting target milestone to 'Future' since 'mozilla1.1alpha' has already passed.
Target Milestone: mozilla1.1alpha → Future
|
||
Comment 15•22 years ago
|
||
I've seen this also, with Moz/1.1 and the onclick being a window.close() (which
stops you seeing the alert, which is a pain...)
|
|
||
Updated•22 years ago
|
Whiteboard: [T2]
|
||
Comment 16•22 years ago
|
||
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity. Only changing open bugs to
minimize unnecessary spam. Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.
Severity: normal → critical
|
|
||
Comment 17•22 years ago
|
||
Reassigning futured nsbeta1+ bugs to Samir in case he wants to find people that
can pay attention to them.
Assignee: danm → sgehani
Status: ASSIGNED → NEW
|
||
Comment 18•22 years ago
|
||
Dialog modality is a pretty important issue, I think. We have to get this right.
|
|
||
Comment 19•22 years ago
|
||
Clarifiying summary with additions taken from comment #2
Summary: Modal dialogs (alert, confirm, prompt) do not halt code execution → Modal dialogs (alert, confirm, prompt) do not halt code execution of all other scripts on that page
|
||
Comment 20•22 years ago
|
||
Over to default owner.
Assignee: sgehani → dom_bugs
QA Contact: desale → ashishbhatt
|
||
Comment 21•22 years ago
|
||
Linux version - mozilla1.4b, try this:
function CrazyAlert(i)
{
setTimeout("CrazyAlert("+(parseInt(i)+1)+")", 100);
alert(i);
}
CrazyAlert(0);
|
||
Comment 23•21 years ago
|
||
I'm having a little trouble finding a crash testcase for this bug. The testcase
mentioned through bug 57231 points to a dead domain name (at least for me). Can
we have a crash testcase placed as an attachment to this bug?
|
||
Comment 24•20 years ago
|
||
Bug 267575 seems to be related. Is it a dupe?
|
|
||
Updated•19 years ago
|
Attachment #75737 -
Attachment description: testcase with code from #4 → testcase with code from #4: alerts in both onmousedown and onclick lead to stacked dialogs
|
||
Comment 25•18 years ago
|
||
The test in comment 21 causes 178 modal windows to open on my system followed by a window with two buttons that don't have any text on them and do nothing when clicked.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060526 BonEcho/2.0a3
|
|
||
Comment 26•18 years ago
|
||
Here is a screenshot depicting what I am seeing. I dragged the top modal window down so you can see the one under it.
|
|
||
Comment 27•18 years ago
|
||
*** This bug has been marked as a duplicate of 52209 ***
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•