Ravi Pinjala Reporter
	Description • 16 years ago

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.1) Gecko/2008072712 (Gentoo) Firefox/3.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.1) Gecko/2008072712 (Gentoo) Firefox/3.0.1

As far as I can tell, this is expected behavior, if only because it's been in firefox (and other browsers?) for so long. However, it's a fairly serious bug - probably more serious than an outright browser crash, since a) the user has to know how to manually kill a process to get rid of it, and b) the problem persists after restoring tabs, so starting a new session is required. 

To avoid changing the semantics of alert(), it's probably necessary for the active tab contents to remain inaccessible while an alert() dialog is displayed, but in general the user interface controls should *always* be usable, at least in my opinion. 


Reproducible: Always

Steps to Reproduce:
1. Load any malicious website that calls alert() in a loop
2.
3.
Actual Results:  
The browser becomes unusable.

Expected Results:  
The user interface of the browser should continue functioning normally.

	Ravi Pinjala Reporter
	Comment 1 • 16 years ago

D'oh! After submitting, I realized that I'd forgotten to actually describe the problem in the description. The problem is that the user interface (menus, back buttons, tab controls, etc) blocks during calls to alert(), and while it makes sense for the page to block, there are no circumstances where it's acceptible for a page to prevent the user from accessing the user interface as a whole.