New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 456 link

Starred by 396 users

Comments by non-members will not trigger notification emails to users who starred this issue.

Issue metadata

Status: Fixed
Closed: May 2017
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

  • Only users with EditIssue permission may comment.

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

Javascript alerts are modal to Chrome UI, not to individual tab.

Reported by, Sep 3 2008

Issue description

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-
Showing comments 13 - 112 of 112 Older

Comment 13 by, Jun 1 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.
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.

Comment 15 by, 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.

Comment 16 by, Jun 16 2009

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

Comment 17 by, Jul 6 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.
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.

Comment 19 by, Jul 16 2009

FWIW, an additional "Prevent this webpage from creating new dialogs" has been 
 Issue 26361  has been merged into this issue.

Comment 21 by, Dec 15 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

Comment 22 by, Dec 18 2009

Labels: -Area-BrowserUI Area-UI-Features
Area-UI-Features label replaces Area-BrowserUI label
I noticed Opera is implementing tab-modal alert boxes in Opera 10.5.  
Chrome should do something similar.

Comment 24 by, Jan 4 2010

OpenFileDialogs and SaveFileDialogs also have this non-tab-specific behaviour and 
should also be tab-modal. Not only the JavaScript alerts

Comment 25 by, 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. 
zelidrag: If you're doing something here, talk to ( trungl on 
irc, ) first.

Comment 28 by, Jan 13 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.
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

BUG= 456 , 27585 , 27620 
TEST=Go to http://www/~thakis/cgi-bin/test.html, hit esc.

Review URL:

 Issue 31377  has been merged into this issue.

Comment 31 by, Feb 6 2010

please also take a look at  Issue 3531  to see if it is a duplicate (it has a testcase)
Labels: Area-UI
Labels: -Area-UI-Features

Comment 34 by, 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

Comment 35 by Deleted ...@, 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.
@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?
@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.
 Issue 48961  has been merged into this issue.

Comment 39 by, 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.

Comment 40 by Deleted ...@, 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.
 Issue 61369  has been merged into this issue.
Yeah. In Chrome Youtube Video it says all are not modal.. whats now? It is...

Comment 43 Deleted

Comment 44 by, Oct 31 2010

+1 (I don't care what the help text says)

Comment 45 Deleted

Comment 46 by, Nov 10 2010

 Issue 62661  has been merged into this issue.
This issue not only affects the current window, but ALL windows.  An open alert prevents interaction, closure, or even viewing, on other windows.

Comment 48 by, Dec 14 2010

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

Comment 51 by, 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.
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.

@52, the browser already offers to block further dialogs on the page.
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.
@54 It's never "too late" to block further dialogs. The option is included directly in the alert. No need to kill the process.

Comment 56 by, 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".
@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.

Comment 58 by, 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.
If you want to close the tab upon seeing a dialog, the resolution of this issue should allow that.
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.
@all check this it comes again, and again, ... and... again! I think this is what @54 mean
@61: That's interesting.  As a side note, I got it to stop by checking "Disable alert boxes" and then hitting "Cancel".

Comment 63 by, Apr 6 2011

@62 It doesn't halt script execution, though, which is the crux of the problem.

Comment 64 by, 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

Comment 65 by, Apr 6 2011

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.

Comment 66 by, Apr 6 2011

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 :)
Labels: Restrict-AddIssueComment-Commit
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.

Comment 68 by, Aug 7 2011

 Issue 91938  has been merged into this issue.

Comment 69 Deleted

Comment 70 by, Feb 24 2012

 Issue 114819  has been merged into this issue.

Comment 71 by, Sep 12 2012

 Issue 148591  has been merged into this issue.
Project Member

Comment 74 by, Mar 10 2013

Labels: -Area-UI Cr-UI

Comment 75 by, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Comment 76 by, Jul 24 2013

 Issue 311568  has been merged into this issue.
 Issue 342421  has been merged into this issue.
Labels: -Mstone-X
Owner: ----
Status: Available
Looks like no one is working on this. Changing the status and removing the owner.
 Issue 142079  has been merged into this issue.
 Issue 442604  has been merged into this issue.
 Issue 448788  has been merged into this issue.
 Issue 448788  has been merged into this issue.

Comment 84 by, Feb 13 2015

Labels: Cr-Blink-Window-Dialog

Comment 85 by, Apr 30 2015

 Issue 483115  has been merged into this issue.
Issue 336069 has been merged into this issue.
 Issue 489828  has been merged into this issue.
Labels: -Cr-Blink-Window-Dialog Cr-Blink-WindowDialog
Manually move Cr-Blink-Window-Dialog to Cr-Blink-WindowDialog

Comment 89 by, Sep 1 2015

Labels: M-47
"Anything from the web that uses alerts (or modals) gets complete control over the whole Chrome UI, and that just feels very wrong."

Kind of surprised this bug is still open after 8 years.  And, look at all the duplicate bugs that have been merged in!  Clearly, this is something that needs to be addressed.

The problem is quite simple: a modal dialog is freezing all other browser tabs and windows.  The solution is equally simple: The modal dialog should only freeze the tab that opened it.

Regarding darin@'s comment (#67 above),  I don't see how the web platform has to change at all for us to solve this problem.  The API can remain synchronous, just as it is now.  It only needs to block the tab that opened the dialog (and not all other tabs as well).

More examples of [poor] user experiences posted on chromium-discuss@ recently:

"I've noticed that when a tab creates a popup, it's very annoying when you can't click on other tabs."

"A minimized Chrome window (or one on a different virtual desktop) can open a modal dialogue which freezes focus and user input to all Chrome windows on the current visible desktop.  Happens frequently to me when Google Calendar puts up a reminder modal.  Makes it seem like Chrome has frozen and needs to be force-killed."

miu: The problem is that several tabs can end up in a single renderer process, and you really block a single renderer, not a single tab. So you have a small subset of tabs blocked on a modal dialog, and it's not clear how this should work ui-wise.

Comment 91 by, Sep 2 2015

Ah, yes.  Makes sense now.  So, to summarize, our options are:

1. Solve a hard problem (probably low ROI) to continue supporting synchronous modal dialogs.
2. Stop supporting synchronous modal dialogs (i.e., alert() and friends do nothing).
3. Adopt other browsers' approach to provide an asynchronous solution.
4. Do nothing and ignore this bug.
I'm a fan of #2.

Comment 93 by, Oct 15 2015

 Issue 375906  has been merged into this issue.

Comment 94 by, Oct 15 2015

 Issue 358785  has been merged into this issue.

Comment 95 by, Oct 15 2015

 Issue 282654  has been merged into this issue.

Comment 96 by, Oct 15 2015

 Issue 498243  has been merged into this issue.
 Issue 3531  has been merged into this issue.

Comment 98 by, Mar 25 2016

 Issue 562314  has been merged into this issue.

Comment 99 by, May 7 2016

 Issue 609552  has been merged into this issue.

Comment 100 by, May 26 2016

 Issue 614774  has been merged into this issue.

Comment 101 by, Jun 27 2016

So, rather than try to "fix" modal dialogs, I propose we just eliminate them altogether. IMHO, even when websites use them as part of a legitimate user workflow (e.g., Google Calendar notifications), their use pretty much never results in a good user experience. They're an unwelcome interruption, and one that takes full control and freezes the rest of the browser UI (all browser windows).

I sought out this bug again just now because a friend of mine e-mailed me a link to a malicious website that "broke Chrome." What happens is that this website repeatedly pops open modal dialogs forever, and the user cannot regain control of the browser to close the tab. When the user clicks Chrome's checkbox to "Prevent this page from creating additional dialogs," the page then displays a pixel-perfect screenshot of the same modal dialog to fool the user into thinking that it didn't work (and so Chrome must be broken). Even worse, when the user clicks on the "fake" dialog, the page opens another window with a copy of itself, and the cycle of pain starts again.

Instead of fixing the UI around modal dialogs, maybe we should be asking: Can anyone provide a good reason to KEEP modal dialogs?
 Issue 633548  has been merged into this issue.

Comment 103 by, Sep 15 2016

 Issue 647062  has been merged into this issue.

Comment 104 by, Sep 26 2016

 Issue 628916  has been merged into this issue.
Status: Assigned (was: Available)
Avi, you're working on fixing this, right?
This bug is asking for tab-modal dialogs, and I'm working on auto-dismissing dialogs, but yes, once I get autodismissal working then I certainly would call this fixed.

I'll take ownership.
 Issue 662512  has been merged into this issue.
 Issue 27484  has been merged into this issue.
Labels: -M-47
Avi - could you add the milestone you expect this to be fixed in by your work? Or add a NextAction date so we know when to check back in?
Labels: M-57
With any luck, this will stick in M57. Right now 57 in beta is in a 50/50 trial for this.
 Issue 698076  has been merged into this issue.

Comment 112 by, May 31 2017

Status: Fixed (was: Assigned)
Given auto-dismissing dialogs are implemented in  bug 629964  and enabled permanently now, I'm calling this fixed.
Showing comments 13 - 112 of 112 Older

Sign in to add a comment