Proposal: Deprecate alert(), confirm(), prompt()

APIs
1

Proposal: Deprecate alert(), confirm(), prompt()

Motivations

The alert(), confirm() and prompt() APis are more and more being used in malicious ways [7][8], such as keeping a user on the page and not allowing them to leave, mainly by web scams, or abusive advertising (usually by looping the alert box).
On Chrome (iOS) the situation was so bad i would have to restart the phone, as re-opening the browser would just reload the page. I belive this has now been fixed[1]

These dialogs are synchronous in their nature which means the javascript engine needs to pause until a response is obtained, sometimes locking up the whole browser. There is work being done to seperate such tasks, however on some phones the whole browser still locks up.

Chromium’s latest policy no longer condones the usage of these Apis either[2]

Test Case

Here i haven’t included an infinite loop, but only 6 iterations to show what happens.

What is being done?

Chromium have blocked alerts() from being called in an unload handler[3] but this isn’t enough, pages have got around this by starting the loop once you enter the page.
Chrome iOS have now added a supress option in their browser[1]
Window.showModalDialog() has been deprecated and removed in hrome 43, and Firefox 55. [4]

Alternatives

The Notifications API[5] is very useful and should be used for notifiying the user of events, and has good basic support across all modern browsers. For those needing to gain user input [6] should be used instead. I understand dialog is not well supported across modern browsers yet, Google have provided a polyfill untill this is the case https://github.com/GoogleChrome/dialog-polyfill.

Having dialogs native in the browser should reduce the concern of overhead (needing scripts, plugins just to show a confirmation/alert box).

With these alternatives in place, and a comprehensive set of tools in the web ecosystem i believe there is no need to ever use these APIs anymore and thus should be deprecated from the specification

Issue posted here:

1: https://bugs.chromium.org/p/chromium/issues/detail?id=485969
2: https://developers.google.com/web/updates/2017/03/dialogs-policy
3: https://bugs.chromium.org/p/chromium/issues/detail?id=68780
4: https://developer.mozilla.org/en/docs/Web/API/Window/showModalDialog
5: https://developer.mozilla.org/en-US/docs/Web/API/Notifications_API
6: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog
7: https://support.mozilla.org/en-US/questions/690130
8: https://discussions.apple.com/thread/7045611?start=0&tstart=0

2 Likes
2

Chromium also is investigating making dialogs not block things. This is Project Oldspice.

The Notifications API isn’t always a good replacement. It’s highly dependent on the cases where you should use native notifications compared to in-page ones.

The Dialog element is the best choice to encourage more. It has the ability to provide the same type of experience to users that the current experiences offer. So the existing training of users carries directly over.

3

I agree these should be deprecated, but absolutely not until dialog has widespread support (without a polyfill). Even Chrome’s native implementation could be improved in a few ways.

FWIW, I did have an idea recently that would override alert, confirm, and prompt by using dialog elements. I haven’t gotten around to it, but can certainly do so if people are interested.

Also, I’m not sure notifications are an appropriate replacement for alert. Notifications also require permission from the user in most (all?) browsers.

4

Deprecation could go forward just fine even without widespread dialog element support. Deprecation doesn’t mean it is immediately removed. It’s more of a nudge to get users to stop using it and take up alternatives. Later, in this case way later, when usage is low enough then browsers can remove things if they desire. I mean, <center> is still implemented and it has been deprecated for a good while.

2 Likes
5

I actually respectfully disagree with this proposal. I believe browsers should offer options for dealing with malicious uses, but I think that alert/confirm/prompt provide excellent tools both for debugging and for helping novice programmers learn coding, without the hassle of needing to approve notifications… Please don’t deprecate these, especially since they are already a long-time part of the web… Let’s not break the web, even where modern sites should, for good design, indeed be using dialog as it becomes available… :worried:

2 Likes
6

Deprecation != removal

7

If “deprecated” no longer has the connotation that it will eventually be phased out, then sounds good to me as per your own caveats of getting dialog supported natively (if not improved perhaps by using Promises)…

Beyond my already stated reasons, I think we also have a duty to preserve website functionality for posterity…

8

I think that alert/confirm/prompt provide excellent tools both for debugging and for helping novice programmers learn coding, without the hassle of needing to approve notifications

Browser provided Developer Tools are far more robust and give much more insight into your entire application state when debugging. Far superior to alert methods. New programmers learning should be far more encouraged to use DevTools over alert methods.

I think we also have a duty to preserve website functionality for posterity

Well, we can’t break the web. The proposal is they be deprecated by the spec. And if over time (this would be literally loads of time because a lot of apps rely on these and don’t get updated) the usage count becomes low enough, then browsers could be safe in removing them.

9

Google chrome from version 69 broke it… For my opinion it is dumbest excuse ever to remove useful functionality in the name of abuse! Also if tabs are abused, than tabs also will be deprecated and removed ? If only base page left and be abused, then deprecate browser as a such? Maybe solution is just allow user to harden user level of “safeness”, if user wants to visit troublesome internet resources? Why window.confirm() method gets TRIGGERED with false results??? If it would be deprecated correctly it would not answer question with “NO” by “clicking” buttons in the name of user! In an older project there are a lot of confirmations for printing etc., Now they all are answered “NO” as if user clicked button “NO”! Correct implementation would remain dialog in the tab, but just do not activate that tab as it was requested. Current implementation/deprecation just broke a lot of legimitate code by doing incorrect actions behind the user. Maybe just NOT to cut off useful functionality because of “we can”?

1 Like
10

We need to do something smarter than deprecation. It would be great to do the following:

1. implement asynchronous version of prompt and confirm. Currently we have synchronous confirm() and prompt():

window.prompt(message, defaultValue) //returns string
window.confirm(message); //returns boolean

We can run these calls from async context ( http://jsfiddle.net/z9vbqo3x/ ), but it would be better to implement truly asynchronous version of prompt and confirm. We need something like this:

window.prompt(message, defaultValue, async); //return Promise if async == true;
window.confirm(message, async); //return Promise if async == true;

2. Make alert() asynchronous.

3. Ignore alert, confirm and prompt that executed not in context of user-initiated events. (see also [Proposal] Permission requests should be available only in context of user-initiated events)

12

I think browsers should allow blocking-prompts to be disabled for particular origins, similar to how ad-blocking works. This would help create disincentivization push. They could start with a dialog that lets the user disable blocking UI on an origin the first time it tries to open something (this might break the site but now the finger pointing is on the user, not the browser). Later they can start blocking sites with known aggressive blocking UI (perhaps using the disable metrics), and make usage mutually exclusive to more powerful web features (eg if I use a Service Worker I automatically opt-out of blocking UI working). Then with the main push complete, it can revert to an opt-in-only feature like how Flash was wound down where I need to go into settings to re-enable it.

13

Another example of Prompt() holding you hostage here https://twitter.com/DasSurma/status/1140691211021406214