Chrome’s JavaScript Popup Handling Changes

It’s surprising that Chrome has taken so long to implement changes that protect users from malicious pop-up ads; Firefox took care of this problem years ago.

Google implemented a change in Chrome’s JavaScript popup handling behavior recently that restricts JavaScript popups. The change, which landed in Chrome Canary and Dev already, improves the handling of JavaScript alert(), confirm() and prompt() dialogs that pages may throw in the browser. Chrome up until now, and that is still true for Chrome Stable and Beta, handled these JavaScript dialogs per browser-window.

This mean that popups could lock the browser until users reacted to the popup in question. While that may be useful in certain situations, it often meant that sites used these options to lock the browser and force users to interact with the popup.

This ranged from prank sites that put you in an endless loop of popups to attack sites that asked users to pay up to remove the popup and return the browser to its default state.

Chrome’s JavaScript popups handling changes

google alert

Google made the decision to make these JavaScript dialogs work on a per-tab basis in the browser, and no longer on a per-window basis. What this means for users is that it is now possible to dismiss any popup thrown by these JavaScript functions by simply switching tabs.

Doing so dismisses the popup right away. Users don’t have to interact with the popup directly anymore, or even force kill the Chrome process to regain control over the web browser.

The company notes on the official design document:

If a tab is the foremost tab, then we would present the dialog for the tab. alert/confirm/prompt dialogs would then be displayed and focused for user interactions. If the user interacts with them and performs the user interaction they are designed for, then nothing notable would happen.

However, if the user were to switch to a different tab, moving the tab into the background and making it not foremost, we would dismiss the dialog. For alert dialogs, the JavaScript isn’t waiting for a response, so we would return to the JavaScript. For confirm and prompt dialogs, we would return false and null respectively, indicating a cancellation. (Note that these are the same values that we currently return for dialogs that are suppressed by the “Prevent this page from creating additional dialogs” setting.)

For all other tabs, we would neutralize most of the dialogs. For alert dialogs, we would add it to a queue for that tab, and show the queue of dialogs the next time the tab is in the foreground, but we would immediately allow the JavaScript of that tab to resume. For confirm and prompt dialogs, we would immediately return false/null to prevent the JavaScript from blocking, as blocking the script execution would break arbitrary tabs, quite possibly the one that the user is interacting with.

The change should put an end to webmasters using these JavaScript functions to annoy or attack users of the Chrome browser.

Google notes that the change will affect all sites that make use of these JavaScript dialogs. The company suggests that sites implement alternatives, for instance using the Notifications API instead.

Does this mean that Google will change Google Calendar’s use of alert() for notifications? Only time will tell.

If you look at other browsers, you will notice that they have implemented the functionality years ago. Both Firefox and Opera have had this option implemented for years.

Link to Original Content

Tags: , , ,

Comments are closed.