My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 456: Javascript alerts are modal to Chrome UI, not to individual tab.
298 people starred this issue and may be notified of changes. Back to list
Status:  Available
Owner:  ----

  • Only users with EditIssue permission may comment.

Sign in to add a comment
Reported by, Sep 3, 2008
Product Version      :
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 3: UNTESTED
    Firefox 3: FAIL
         IE 7: FAIL

What steps will reproduce the problem?
1. Go to
2. Imagine that this is a nasty website that you wish to terminate without 
clicking either button
3. Try to close the current browser tab

What is the expected result?
Tab can be killed.  The cartoon says that each tab is a separate process, 
which can be independantly closed if the user wishes. 

What happens instead?
The dialog is modal across the entire browser, rendering the entire Chrome 
session unusable until either OK or Cancel is clicked.  It is not possible 
to close the offending tab.

Please provide any additional information below. Attach a screenshot if 

A similar situation is described at http://saalwaechter-
Sep 4, 2008

Opera 9: JavaScript can be disabled in the alert dialog.
Sep 5, 2008
Yes, i confirm this browser problem. The javascript alert() dialog cannot be modal 
for the entire chrome. Must be modal just by the tab that call it, and the tab MUST 
accept be closed with the alert on screen.
Sep 6, 2008
Various technical limitations led to this unfortunate detail :-/

Darin thinks this problem can be solved now however, so I imagine this will be 
completed in a future release.
Status: Untriaged
Labels: -Area-Unknown Area-BrowserUI
Sep 12, 2008
This has been a major annoyance ever since Tabbed browsers came to be, and it pains 
me nobody has dealt with this by making alerts "stick" to their parent tab.

I'd have thought Mozilla would have done this, seeing as they created some internal 
elements and attributes for Firefox. 

Oct 2, 2008
(No comment was entered for this change.)
Oct 3, 2008
Star the issue instead of saying +1
Oct 21, 2008
(No comment was entered for this change.)
Status: Assigned
Labels: Mstone-X
Nov 20, 2008
This is also problem for other Chrome windows. The alert box is modal for tabs in 
other Chrome windows.

I'm not sure how useful this dual view bookmarklet is with this issue.
Dec 31, 2008
 Issue 5813  has been merged into this issue.
Dec 31, 2008
 Issue 3658  has been merged into this issue.
Feb 15, 2009
#11 t.broyer
Note that authentication boxes have the expected behavior: you can switch from tab to 
tab (including using the keyboard) and close the tab (including with the keyboard) 
without the need to dismiss the dialog box first.

To reproduce, open in another tab and start 
playing around.
Mar 27, 2009
 Issue 4455  has been merged into this issue.
May 31, 2009
Just like the authentication boxes, the Javascript alerts should only effect the 
viewing area on a single tab, not an entire tab. No Javascript alert should stop the 
user accessing the bookmark tool bar or address bar.
May 31, 2009
#14 phistuck
How about making it modal to the tab and also - make the tab blink (or whatever) whenever 
there is an open alert\confirm\prompt box while it is not focused (like Windows does in the 
I think this is pretty logical.
Jun 16, 2009
But what about a cross-pages application which use function to maintain 
parent-chind windows relationship, the developer may need to block them all when an 
alert box show up.
Jun 16, 2009
#16 phistuck
No, that is bad development of web pages.
You always could close the opened window (as long as it is not a tab in that window) 
while its opener shows an alert box, in any browser (as far as I remember).

Wow, I just noticed that the whole browser is hung until you close that alert box, that is 
bad, bad, bad. :|
Jul 5, 2009
Semi-DoS based on this, as the option to ban javascript popups is forgotten on a page 


You can still manage to close the window with good coordination of Enter + middle-
clicking or Click + Ctrl-W, but the window is only a few tens of milliseconds wide.

It's a DoS for the average user.
Jul 9, 2009
I can’t help but notice that this is still an issue with (20196). What’s more 
is that the similar—at least from a user perspective—proxy authentication dialog ( Issue 
13213 ) is modal only to the associated tab as expected.

Jul 15, 2009
FWIW, an additional "Prevent this webpage from creating new dialogs" has been 
Oct 30, 2009
 Issue 26361  has been merged into this issue.
Dec 14, 2009
Here is a example of intentional misuse of this behavior:'+camera

It creates a browser modal dialog box that acts as a modal pop-up advertisement.  I
have encountered several sites like this over the past few months. One of them looped
infinitely with a dialog, new window, and dialog cycle.

I'm not sure how things stand these days, but some browsers have given elevated
rights for actions that the user initiated with a click.  To be safe, I avoid
interacting with questionable pop up dialogs and I watch the URLs behind links if I'm
not sure what a page is up to.  That makes these browser modal dialog boxes quite
Dec 18, 2009
Area-UI-Features label replaces Area-BrowserUI label
Labels: -Area-BrowserUI Area-UI-Features
Jan 3, 2010
#23 jordonwii
I noticed Opera is implementing tab-modal alert boxes in Opera 10.5.  
Chrome should do something similar.
Jan 4, 2010
OpenFileDialogs and SaveFileDialogs also have this non-tab-specific behaviour and 
should also be tab-modal. Not only the JavaScript alerts
Jan 4, 2010
If chrome goes to this extent (which I hope it does) it would be nice if there a 
graphical way to know that a tab is showing a dialog / blocked.

Currently the HTTP basic authentication dialog is modal per tab, but the tab still 
looks like it is loading (with the circular loading image in place of the favicon on 
the tab moving anti-clockwise).

If more tab-modal dialogs like this are used in chrome, the user should be alerted. 
Some ways to show a tab-modal dialog is showing on another tab could be:
 - Yellow Tab
 - Stop loading... circular motion
 - Replace loading... circular motion with gently pulsing circle (making sure it does 
not distract the user)
 - Change the text on the tab to that of the modal dialog

Please at least change something making sure it does not stand out. If you are 
waiting for dialogs to show on 20 different tabs (HTTP Auth / Javascript or other), 
don't make me check every tab for dialogs. 
Jan 4, 2010
(No comment was entered for this change.)
Jan 4, 2010
zelidrag: If you're doing something here, talk to ( trungl on 
irc, ) first.
Jan 12, 2010
I just encountered a site that uses this feature to attack the user.  The site pretends 
to be a windows update / security application running on the user's local machine.  It 
spoofs the look of windows XP and pops up windows that look like system prompts.  When 
you attempt to close the window the page pops up another modal dialog box, and when you 
click to close the modal dialog box it begins a download.
Jan 15, 2010
The following revision refers to this bug: 

r36415 | | 2010-01-15 13:49:44 -0800 (Fri, 15 Jan 2010) | 12 lines
Changed paths:

Tab-modal dialog improvements:
- treat constrained dialogs as tab-modal - only one shows at the time
- added visual indication (tab pulsing) to the tab strip when a tab is blocked by a tab-modal dialog
- blocked all UI activity from rendrer host and forced refocusing on constrained (tab-modal) dialogs

This CL reverts and instead incorporates the changes from

TEST=Go to http://www/~thakis/cgi-bin/test.html hit esc.

Review URL:

Jan 19, 2010
 Issue 31377  has been merged into this issue.
Feb 6, 2010
please also take a look at Issue 3531 to see if it is a duplicate (it has a testcase)
Feb 17, 2010
(No comment was entered for this change.)
Labels: Area-UI
Feb 17, 2010
(No comment was entered for this change.)
Labels: -Area-UI-Features
Apr 9, 2010
I think the javascript alert should be the same as the new "Confirm Form Resubmission" 
Test it:
Open more tabs in one tab open:
Submit something and then press reload page -> see the dialog -> it's not modal, you 
can change the tab

Confirm Form Resubmission.png
57.1 KB   View   Download
May 8, 2010
When you get redirected to a website that displays a fake "malware detected" Javascript 
alert, on Firefox, you can click on the options and turn on Javascript.

In Chrome, the Javascript alert is modal so you cannot turn off Javascript to prevent 
any further Javascript from running.

I believe you should be able to turn off Javascript when one of these sites displays a 
Javascript alert.
May 8, 2010
#36 jordonwii
@rene.sugar: You know that if a website displays more than one alert box, a checkbox 
appears to disable further alert boxes from that website, right?
May 8, 2010
#37 phistuck
@jordonwii That is correct, but the JavaScript will still keep on executing, it does 
not have to show alert boxes, it can simply keep running and you might just want to 
turn it off.
This is a good argument, in my opinion.
Jul 13, 2010
 Issue 48961  has been merged into this issue.
Jul 17, 2010
This has already been solved by the niceAlert extension; The real problem is doing the same with prompts.
I believe it should have the same look and feel as the 'Chrome crashed. Restore?' prompt.
Oct 5, 2010
Are you guys even gonna properly fix this issue. It's been 2 years, come on, I was struct with this problem on numerous occasions, and am baffled as to why the alert dialog is left modal for the entire application, not even allowing you to close the tab.
Oct 31, 2010
 Issue 61369  has been merged into this issue.
Oct 31, 2010
#42 Kurtextrem
Yeah. In Chrome Youtube Video it says all are not modal.. whats now? It is...
Oct 31, 2010
+1 (I don't care what the help text says)
Nov 10, 2010
#46 ryazanov
 Issue 62661  has been merged into this issue.
Nov 16, 2010
This issue not only affects the current window, but ALL windows.  An open alert prevents interaction, closure, or even viewing, on other windows.
Dec 14, 2010
#48 lealcy
This discussion is still in place? Appears this is a really challenging change in the chromiums code. And it is still plain annoying for me that a simple dialog box freeze the entire browser. I hope you guys improve it soon. Cheers.
Dec 23, 2010
#49 priyajeet
Since Chrome doesn't make modal popups via showModalDialog actually modal to the tab it was launched from, it also causes a browser freeze if a person accidentally minimized a modal popup. While you can work on the main page, navigating away from that page due to some action is all blocked out till that modal popup is closed.

This should be changed, if the popup is not modal then it should not freeze out the main window. Or if there is a modal popup open, some indication on the main page would be nice to alert or nudge the user not to ignore the modal popup.
Mar 4, 2011
#50 priyajeet
In case folks haven't noticed, Firefox 4 alerts/confirms are coming up with an underlay now and the alert popup seems html based (can't inspect it so unsure). Also the alerts/confirms are confined to the tab now.

It would be nice for chrome to also go down this route and make the alerts identical to the DOMUI-Settings modal box that we see with a -webkit-radial-gradiant() eg: Clear Browsing Data
Screen shot 2011-03-04 at 7.23.16 PM.png
194 KB   View   Download
Mar 6, 2011
All I know is when I click "Download" at Mediafire, I often get a popup ad that spawns a Javascript alert, preventing me from closing the parent ad directly.  It's infuriating.

Actually, even with popups that don't pull that trick, the Save dialog itself has a similar effect (as comment 24 mentioned): If I'm a bit too slow, it appears and blocks me from closing the ad popup until I finish picking my download location like a good boy.
Apr 6, 2011
Locking of the entire app on a modal dialog is the *desired* effect by those programming malicious applications.

Since as a user, I hate any time that someone tries to lock up the UI when I am browsing and I consider this to be a primary indicator of malicious intent, how about considering a preferences option that if a page tries to invoke this function, the browser takes over and asks if I would like to close this offending tab.

Apr 6, 2011
@52, the browser already offers to block further dialogs on the page.
Apr 6, 2011
Perhaps that is too late.

Suppose I am browsing to an unknown site. The page is compromised and
the first thing it does is lock up the UI with a dialog box. I am not
sure what will happen on any user input because I know that I am under

Right now, what I usually do is open a text terminal and do a pkill on Chromium.
Apr 6, 2011
@54 It's never "too late" to block further dialogs. The option is included directly in the alert. No need to kill the process.
Apr 6, 2011
@55 I think he is saying (and please correct me if I'm wrong), that once he gets the initial UI lock, he wishes to halt *any* further script processing since he has very good reason to believe that any further scripting would be malicious. If the dialog wasn't modal, he could simply close the tab (which would of course halt further script processing); but, it IS modal, and so clicking "ok" (or whatever is appropriate) on the dialog *must* be done in order to be able to close the tab, but which will also let the page continue to execute script starting from the moment that the dialog is closed. This is what is meant by "too late".
Apr 6, 2011
@55 As far as I know, the option to block further dialogs is not included in the first dialog (only the second, third, etc.).

Another example of when this would be useful: say a webpage pops up a prompt, where I have to enter some text.  However, what I need to enter is a long confirmation code.  I didn't copy it to the clipboard (because I didn't know I would need it), but this pop-up comes up, so I try to switch to another tab to retrieve it.  But I can't switch to the other tab, so I have to close the prompt, and who knows what effect that has on the page's JavaScript.
Apr 6, 2011
Blocking dialogs won't help you to stop this malicious code :)

var counter = {divs:1,spans:1};
while(counter.divs || counter.spans)
  if( confirm("Hello I'm a malicious code which will insert a DOM Element regardless your coice.") )
    $("body").append("<div>Malicious div #"+counter.divs+"</div>");
    $("body").append("<span>Malicious span #"+counter.spans+"</span>");

Having confirms/promts/alerts/onbeforeunload/whatever else modal to individual tabs are better so if you find something suspicious you can simply close the offending tab and prevent the malicious code to be executed.
Apr 6, 2011
If you want to close the tab upon seeing a dialog, the resolution of this issue should allow that.
Apr 6, 2011
#60 jordonwii
But why would any malicious website throw up an alert box?  Looking at the code in #58, the confirm box is completely unnecessary...

However, it does seem awful barbaric to have alert/confirm boxes cause 100% browser lockup, especially for instances like #57.
Apr 6, 2011
#61 Kurtextrem
@all check this it comes again, and again, ... and... again! I think this is what @54 mean
Apr 6, 2011
#62 jordonwii
@61: That's interesting.  As a side note, I got it to stop by checking "Disable alert boxes" and then hitting "Cancel".
Apr 6, 2011
@62 It doesn't halt script execution, though, which is the crux of the problem.
Apr 6, 2011
@60 Have you seen recent advertising from malicious sites which prompts you to register at groupon?

Its something like:

confirm: "this is your great chance to get coupons blah blah blah..."
*creates an ad*
confirm: "are you sure you want to miss this chance blah blah blah..."
*creates another ad*
confirm: "this is a once-in-a-life opportunity, do you really really want to miss it blah blah blah"
*creates even another ad*
onbeforeunload: "this is your last chance to get this offer..."
*fires click() to an ad and closes*

IIRC megaupload has them
Apr 6, 2011
#65 lealcy
Three and a half year of discussions just to not correct this bad design decision of let dialog boxes hang up the browser (inherited from another browsers).

Just copy the Firefox solution.
Apr 6, 2011
#66 perq87
There's already implemented solution exists in this project. Chrome uses non-modal dialogs for authentication dialogs and form resubmission confirms. Maybe it would be harder to implement. I understand that alert calls come from javascript engine but this is against Google Chrome's design (Tab seperation, security, bla bla). Also you (Google) did V8 too :)
Apr 6, 2011
There are too many unhelpful comments in this bug, so I'm restricting comments to committers.

Let me summarize my position.  There are trade-offs here.  Both Mozilla and Opera have implemented tab modal dialogs in a way that have really bazaar side-effects, which cannot be avoided.  They cause developers to have to deal with re-entrancy in their code, and they can cause strange problems if multiples tabs spawn dialogs.  I also think it is a shame that they made these changes as it seemingly reduces the incentives for us as browser vendors to invent a better, asynchronous API for input-modal dialogs.

We have chosen not to go with their solution because we favor stability and sanity for web developers.
Labels: Restrict-AddIssueComment-Commit
Aug 7, 2011
 Issue 91938  has been merged into this issue.
Nov 3, 2011
 Issue 98486  has been merged into this issue.
Feb 24, 2012
 Issue 114819  has been merged into this issue.
Sep 12, 2012
 Issue 148591  has been merged into this issue.
Dec 17, 2012
(No comment was entered for this change.)
Dec 17, 2012
(No comment was entered for this change.)
Mar 10, 2013
(No comment was entered for this change.)
Labels: -Area-UI Cr-UI
Mar 13, 2013
(No comment was entered for this change.)
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Jul 24, 2013
(No comment was entered for this change.)
Oct 28, 2013
 Issue 311568  has been merged into this issue.
Feb 10, 2014
 Issue 342421  has been merged into this issue.
Jun 11, 2014
Looks like no one is working on this. Changing the status and removing the owner.
Status: Available
Owner: ---
Labels: -Mstone-X
Jun 11, 2014
 Issue 142079  has been merged into this issue.
Sign in to add a comment

Powered by Google Project Hosting