Jamie Zawinski Reporter
	Description • 20 years ago

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040116
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040116

If some prank web page decides it's going to go into a loop popping up "OK"
dialogs from JavaScript, I have no way to close the window.

Reproducible: Always
Steps to Reproduce:
    <script language=javascript>
    alert ("dammit");
    alert ("dammit");
    alert ("dammit");
    alert ("dammit");
    </script>

Actual Results:  
Clicking on the window manager "Close" button does not work.

Using Alt+W does not work.

Even if I manage to click on the Close button during the fraction of a second
between dialogs popping up, that doesn't work either (I think.  Maybe I wasn't
fast enough.)

It doesn't even buffer the close-window request and honor it at the end, it just
throws it away.

Expected Results:  
Closing the window from the window manager should always work: it should
unconditionally abort whatever JavaScript thread has taken over the window.

Mozilla 1.6, Red Hat 9.

	Jamie Zawinski Reporter
	Comment 1 • 20 years ago

See also bug 237318 and year-old bug 200409.

	Felix Miata
	Comment 2 • 20 years ago

Doesn't work in OS/2 either. Isn't there already a bug open on this?

	Dan M
	Comment 3 • 20 years ago

*** Bug 200409 has been marked as a duplicate of this bug. ***

	Dan M
	Comment 4 • 20 years ago

Bug 200409 talks about the same problem, but with auth prompts. I move that an
auth prompt is the same thing as a prompt, and these two bugs are identical. As
a nod to that bug, keep in mind that it would arguably be nicer to first trigger
the Cancel button in the prompt (if any), rather than simply shutting both
windows down.

That said, this brings up a really good point. It'll require some cooperation
between the different platforms to implement.

A Windows and OS/2 implementation will be rather involved, since the mechanism
we use to implement alerts is one where the OS eats events sent to the parent
window. A mouseclick in the parent's close box isn't even reported to the alert
as an out-of-bounds event, it's just thrown away. Rewriting modality without
this aid from the OS would return us to a time during development when things
didn't work very well.

Last I looked, the unix and Mac implementations were more homespun and therefore
more amenable to this kind of modification.

	Johnny Stenback (:jst)
	Comment 5 • 20 years ago

One alternative apporach to solving this problem (the DOS attack, at least) is
to limit the number of modal dialogs an app can open in a given time frame, or
some such scheme. Or possibly throwing up another dialog in between the alerts
asking the user if all these alerts are wanted, with an option of killing the
script (and pending timeouts n' what not). That wouldn't solve the other problem
described in bug 200409 tho, so in that sense that bug aint a dupe of this one.

Just tossing out ideas here...

	David Baron :dbaron:
	Comment 6 • 20 years ago

Perhaps alerts could have a Cancel-like button ("Cancel"?  "Abort"?) that would
prevent further alerts from opening?

	Alfonso Martinez
	Comment 7 • 20 years ago

this is the same problem as Bug 66097, that was marked as dup of Bug 61098

	R.K.Aa.
	Comment 8 • 20 years ago

doesn't ctrl+w close the offending tab/window? (it's a bug, but all the same..)

	Jesse Ruderman
	Comment 9 • 20 years ago

*** This bug has been marked as a duplicate of 59314 ***