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)

Product:
Core
Component:
DOM: Core & HTML
Platform:
Other
Windows 98
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 52209
Milestone:
Future

People

(Reporter: tom, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(4 keywords, Whiteboard: [T2])

Attachments

(3 files)

testcase with code from #4: alerts in both onmousedown and onclick lead to stacked dialogs
280 bytes, text/html
Details
comment 21 (can cause unresponsive browser)
188 bytes, text/html
Details
screenshot
71.98 KB, image/jpeg
Details 
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.
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
Sorry, I meant all other scripts on that page - not all browser code.
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
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.
Target Milestone: --- → mozilla1.0
Bug 57507 might be related.
Bug 65943 might be related.  (Button that creates an alert doesn't seem to 
un-depress until you mouseover the alert.)
Keywords: dom0
Blocks: 80296
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
Target Milestone: mozilla1.0.1 → mozilla0.9.8
No longer blocks: 80296
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Blocks: 60280
Blocks: 57231
Keywords: topembed
Target Milestone: mozilla0.9.9 → mozilla1.0
*** Bug 57231 has been marked as a duplicate of this bug. ***
nsbeta1+ per ADT/Embed triage. Caused a crash in bug 57231, which was marked as
a dupe of this bug.
Keywords: crash, nsbeta1+
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
Keywords: topembed → embed, topembed-
Target Milestone: mozilla1.0 → mozilla1.0.1
Target Milestone: mozilla1.0.1 → mozilla1.1alpha
Setting target milestone to 'Future' since 'mozilla1.1alpha' has already passed.
Target Milestone: mozilla1.1alpha → Future
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...)
Whiteboard: [T2]
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
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
Dialog modality is a pretty important issue, I think. We have to get this right.
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
Over to default owner.
Assignee: sgehani → dom_bugs
QA Contact: desale → ashishbhatt
Linux version - mozilla1.4b, try this:

function CrazyAlert(i)
{
  setTimeout("CrazyAlert("+(parseInt(i)+1)+")", 100);
  alert(i);
}

CrazyAlert(0);

adt: nsbeta1-
Keywords: nsbeta1+ → nsbeta1-
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?
Blocks: 238392
Bug 267575 seems to be related.  Is it a dupe?
Attachment #75737 - Attachment description: testcase with code from #4 → testcase with code from #4: alerts in both onmousedown and onclick lead to stacked dialogs
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
Attached image screenshot — 
Here is a screenshot depicting what I am seeing. I dragged the top modal window down so you can see the one under it.

*** 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.

Attachment

General

Creator:
Created:
Updated:
Size: