I can't repro on OSX: I get the checkbox to suppress future dialogs from this page, and when I check it I don't get any other dialogs and can close the tab. Are you saying you don't see "Prevent this page from creating additional dialogs" checkbox?

CC'ing avi who's battling modal dialogs and zbutler for potential SafeBrowsing blacklisting.

I do see a "Prevent this page from creating additional dialogs" checkbox after clicking "OK" and the page immediately appears a second time, however it's ineffective. Checking it and then clicking "OK" opens an identical page (but at a slightly different URL) and the process repeats, opening more and more unclose-able pages (with more and more annoying beeps).

> I do see a "Prevent this page from creating additional dialogs"
> checkbox after clicking "OK" and the page immediately appears a
> second time, however it's ineffective.

I don't see that behavior. When I click the "prevent this page" button, the page uses an in-page pseudo-dialog. If you click the "ok" button in that in-page pseudo-dialog, then the page has the user interaction it needs to open a popup.

If you don't click the "ok" button, you can close it.

I'm curious, as it seems to detect that we're blocking the alert, and it shouldn't be able to do that, but I don't see what we can do here.

I also see the same thing as avi.

> I'm curious, as it seems to detect that we're blocking the alert, and it shouldn't be able to do that, but I don't see what we can do here.

This seems as simple as checking the time before and after alert. When it's blocked, elapsed time is 0ms.

Given these, I'm planning to close the bug as working as intended.

I either don't see the behavior avi describes or am not understanding what he's saying.

- I don't see a "'prevent this page' button". 
- I do see a "Prevent this page from creating additional dialogs" checkbox, which I can check, and then I can click "OK".
- Doing so launches another copy of the same page, in the foreground, which has the same problem.
- Yes, it's true that the original window can now be closed, but the new foreground window has exactly the same problem. There's no way to close it (other than to repeat this process, which will launch yet another unclose-able window.)

Fortunately, a "Deceptive page ahead" warning page has just recently been placed on this site, so it's harder to get to the page, and even if you do, it's easy to get out of the loop because each re-launched copy also has a "Deceptive page ahead" warning page. But that doesn't fix the original vulnerability, which can be observed by pretending that the "Deceptive page ahead" is not there and always clicking through to the site, to see that this behavior continues to occur.

> - I don't see a "'prevent this page' button". 

I meant a "Prevent this page from creating additional dialogs" checkbox.

> - I do see a "Prevent this page from creating additional dialogs" checkbox, which I can check, and then I can click "OK".

I see this too.

> - Doing so launches another copy of the same page, in the foreground, which has the same problem.

I don't see this. This should be prevented by our pop-up blocker. DO NOT click the "OK" "button" in the window itself. You click the "Prevent this page from creating additional dialogs" checkbox in the REAL dialog, then the OK button in the REAL dialog, then close the tab. Do not click any fake dialog stuff in the window.

If I do that, no new windows pop up for me.

> - Yes, it's true that the original window can now be closed, but the new foreground window has exactly the same problem.

That sounds like a bypass of our popup blocker, but I'm not seeing that. Can you screen-record, or in some other way confirm how they're bypassing the popup blocker?

Reproduced it just now on Version 53.0.2748.0 canary (64-bit) Canary,
which does NOT have the "Deceptive page ahead" warning page.

On Canary it's easier to get out of the loop.
- Click "OK" button on first pop-up dialog.
- Click "OK" on second pop-up dialog.
  It relaunches the same page.
  Now "Prevent this page from creating additional dialogs" checkbox appears.
- Check the checkbox.
- Click OK
- Now can click to close the tab or the window.

So I can understand that on Canary, this might be Working-As-Intended, however it's hard for me to imagine that most users will understand how to navigate through this maze to close the tabs, particularly given the dire warnings in the text to not close or shutdown and instead call them for help.  Is there a way to improve the UI?

For example, why do we give modal dialogs such ultimate power to disable so many controls. What if instead when in this state, clicking to close a tab, or close a window, brought up a Chrome warning dialog that said "this web page has disabled closing this tab, click here if you really want to close it".

"why do we give modal dialogs such ultimate power to disable so many controls."

That is  bug 456 , and I _am_ planning to fix it; I wrote up a proposal called "OldSpice": https://docs.google.com/document/d/1wtV5rmLhbf1OZkbg7crtCt6h1mMtig_ctTQt3BLLEIU/edit

But ultimately, even if I do OldSpice, which will bring us to parity with Safari and Firefox, we still have a webpage that blasts warning audio and within its content area tells users to call the scam phone number. I'm not sure what we can do about that.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot