4 ms·

Just a quick note, alert/prompt/etc are NOT in danger of being deprecated. Chrome is just considering not allowing them to be triggered from iFrames for securit

Just a quick note, alert/prompt/etc are NOT in danger of being deprecated. Chrome is just considering not allowing them to be triggered from iFrames for security reasons.

chrismorgan 5y ago
No, blocking them from iframes is just the first step. alert/confirm/prompt are absolutely in danger of being deprecated and eventually removed. Browser makers have declared they’d like to remove them altogether: https://github.com/whatwg/html/issues/2894 https://github.com/whatwg/html/issues/2894. But they’re too popular to remove under current policies unless they’re really causing harm, and I do believe there’s serious risk of them classifying it that way. (They’re actually a bit of a maintenance burden, as three of the few remaining synchronous things.) Remember also the big difference between deprecation and removal. I’d go so far as to say I think it’s likely that alert/prompt/confirm will be deprecated and produce console warnings in at least one major browser before four years pass, though I don’t believe they’ll yet have justified going ahead and removing it.
- gkoberger 5y ago
  Your link says the exact opposite of everything you wrote. The post is by a random dev who doesn't work at a browser, and it was closed by someone who does after they said they don't deprecate things unless they plan on removing them.
  - chrismorgan 5y ago
    It’s definitely not the best source—the best sources are scattered about the place and probably more just murmurings than clear statements of intent—but it does include one positive signal from browser and spec makers, annevk on the reason for reopening it: > I figured it deserved some more implementer input especially since there seems to be interest in removing them eventually It’s not spelled out clearly, but I believe from what I’ve seen of processes there and from what I’ve read elsewhere that he’s talking about implementer interest rather than just-anyone interest. Consider also how Chromium actively gathered usage statistics and Firefox wants to, which you only do if you want to remove the thing. They definitely want to remove it altogether, they just don’t reckon it’s feasible at this time, and it’s definitely not a high priority for them. There are other sources, most likely to be found in previous discussions on HN of this rough topic, but regular search for this stuff is just about impossible now because it’s been drowned by stuff pertaining to the block in cross-origin subframes. (bryik and anonydsfsfs have now found better citations, refer to their comments.)
  - wellthisishn 5y ago
    The link titled "Deprecate alert(), confirm(), prompt()"?
    - wellthisishn 5y ago
      I dunno, why did the OP cite this?
    - gkoberger 5y ago
      Yes, it's an issue created by a random person on GitHub.
  - asddubs 5y ago
    I think they may have meant to link this instead: https://github.com/whatwg/html/issues/6897#issuecomment-885773622 https://github.com/whatwg/html/issues/6897#issuecomment-8857... there's also another reply to the parent with a link to the chromium issue tracker confirming this
  - ricardobeat 5y ago
    That someone in the WhatWG thread works for Google, and is the same person saying they will be removed in the chrome developer mailing lists, quoted and linked above. In fact, almost every argument for their removal seems to be made by the same person. There doesn’t seem to be any other evidence of browse makers having consensus on this.
bryik 5y ago
> We’re on a long, slow path to deprecate and remove window.alert/confirm/prompt and beforeunload handlers due to their role in user-hostile event loop pausing, as well as phishing and other abuse mechanisms. We’ve been successfully chipping away at them in various cases, e.g. background tabs, subframes with no user interaction, and now cross-origin subframes. Each step is hard-fought progress toward the eventual goal, and we should consider carefully whether we want to regress, even in an opt-in manner. https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXiBj3D6A/m/Ut5AZXwuBAAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXi...
- ricardobeat 5y ago
  I wonder what is user-hostile about it. Users have no concept of the event loop. Can’t remember being harmed by an alert() since forever. Last time was probably six or seven years ago when pop-under ads where still a thing.
  - travisd 5y ago
    Alert (essentially) blocks the main UI thread. This means that if you have a while(true){alert} kind of thing, it can be impossible to exit the page since you first have to exit the dialogue before you can take any other action (but of course the dialogue is immediately retriggered). This is better nowadays, but can still cause issues.
    - another-dave 5y ago
      I'd love to see figures on how many people this hits in the wild, especially since you have the "prevent this site creating more dialogs" option.
    - ricardobeat 5y ago
      This was solved many years ago by having dialogs scoped to the active tab. You can just close the tab.

Just a quick note, alert/prompt/etc are NOT in danger of being deprecated. Chrome is just considering not allowing them to be triggered from iFrames for security reasons.

chrismorgan 5y ago

No, blocking them from iframes is just the first step. alert/confirm/prompt are absolutely in danger of being deprecated and eventually removed. Browser makers have declared they’d like to remove them altogether: https://github.com/whatwg/html/issues/2894 https://github.com/whatwg/html/issues/2894. But they’re too popular to remove under current policies unless they’re really causing harm, and I do believe there’s serious risk of them classifying it that way. (They’re actually a bit of a maintenance burden, as three of the few remaining synchronous things.) Remember also the big difference between deprecation and removal. I’d go so far as to say I think it’s likely that alert/prompt/confirm will be deprecated and produce console warnings in at least one major browser before four years pass, though I don’t believe they’ll yet have justified going ahead and removing it.

gkoberger 5y ago
Your link says the exact opposite of everything you wrote. The post is by a random dev who doesn't work at a browser, and it was closed by someone who does after they said they don't deprecate things unless they plan on removing them.
- chrismorgan 5y ago
  It’s definitely not the best source—the best sources are scattered about the place and probably more just murmurings than clear statements of intent—but it does include one positive signal from browser and spec makers, annevk on the reason for reopening it: > I figured it deserved some more implementer input especially since there seems to be interest in removing them eventually It’s not spelled out clearly, but I believe from what I’ve seen of processes there and from what I’ve read elsewhere that he’s talking about implementer interest rather than just-anyone interest. Consider also how Chromium actively gathered usage statistics and Firefox wants to, which you only do if you want to remove the thing. They definitely want to remove it altogether, they just don’t reckon it’s feasible at this time, and it’s definitely not a high priority for them. There are other sources, most likely to be found in previous discussions on HN of this rough topic, but regular search for this stuff is just about impossible now because it’s been drowned by stuff pertaining to the block in cross-origin subframes. (bryik and anonydsfsfs have now found better citations, refer to their comments.)
- wellthisishn 5y ago
  The link titled "Deprecate alert(), confirm(), prompt()"?
  - wellthisishn 5y ago
    I dunno, why did the OP cite this?
  - gkoberger 5y ago
    Yes, it's an issue created by a random person on GitHub.
- asddubs 5y ago
  I think they may have meant to link this instead: https://github.com/whatwg/html/issues/6897#issuecomment-885773622 https://github.com/whatwg/html/issues/6897#issuecomment-8857... there's also another reply to the parent with a link to the chromium issue tracker confirming this
- ricardobeat 5y ago
  That someone in the WhatWG thread works for Google, and is the same person saying they will be removed in the chrome developer mailing lists, quoted and linked above. In fact, almost every argument for their removal seems to be made by the same person. There doesn’t seem to be any other evidence of browse makers having consensus on this.

bryik 5y ago

> We’re on a long, slow path to deprecate and remove window.alert/confirm/prompt and beforeunload handlers due to their role in user-hostile event loop pausing, as well as phishing and other abuse mechanisms. We’ve been successfully chipping away at them in various cases, e.g. background tabs, subframes with no user interaction, and now cross-origin subframes. Each step is hard-fought progress toward the eventual goal, and we should consider carefully whether we want to regress, even in an opt-in manner. https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXiBj3D6A/m/Ut5AZXwuBAAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXi...

ricardobeat 5y ago
I wonder what is user-hostile about it. Users have no concept of the event loop. Can’t remember being harmed by an alert() since forever. Last time was probably six or seven years ago when pop-under ads where still a thing.
- travisd 5y ago
  Alert (essentially) blocks the main UI thread. This means that if you have a while(true){alert} kind of thing, it can be impossible to exit the page since you first have to exit the dialogue before you can take any other action (but of course the dialogue is immediately retriggered). This is better nowadays, but can still cause issues.
  - another-dave 5y ago
    I'd love to see figures on how many people this hits in the wild, especially since you have the "prevent this site creating more dialogs" option.
  - ricardobeat 5y ago
    This was solved many years ago by having dialogs scoped to the active tab. You can just close the tab.