JavaScript Dialogs Are on the Chopping Block — and That Worries Us

For many developers, alert() is the first thing they ever learn in JavaScript. It’s also one of the oldest parts of the web platform, which is precisely why a plan to deprecate it has stirred up so much controversy.

The issue first caught our attention at CodePen, where a Chrome update removed alert()—along with confirm(), prompt(), and related native dialogs—from working inside cross-origin iframes. That’s not an edge case for us; cross-origin iframes are the core of how CodePen executes user code. We woke up to a wave of support tickets from users whose Pens were suddenly broken.

We understand the reasoning. JavaScript dialogs look identical whether they come from an iframe or the parent page, which can be confusing when a third-party embed triggers one. They also block the main thread while open, which halts everything else on the page. Chrome cites these as security and performance concerns, and the plan is reportedly to remove these dialogs from cross-origin iframes first, then eventually from the web platform entirely. That timeline has pushed the cross-origin removal to January 2022, but the long-term goal remains.

What frustrates us is that a solution already exists. The sandbox attribute on iframes offers fine-grained control. You can lock down an iframe so it can’t submit forms, trigger downloads, request device access, or even run JavaScript at all—unless you explicitly allow it. There’s also an allow-modals keyword specifically for controlling dialog access. Why that’s not sufficient is unclear, but the trajectory suggests it’s just a stepping stone toward full removal.

This is spearheaded by Chrome, with the status report noting Firefox and Safari are on board. It’s also been added to the HTML spec. Still, the sheer number of tutorials, games, and internal tools that rely on these functions makes the removal feel reckless.

Not Just an Annoyance — a Control Structure

The loss of alert() might be tolerable, but confirm() is another matter. It returns true or false, meaning it acts as a logical control structure in applications. Flows like account deletion or form submission checks depend on it. As Dan Abramov pointed out, a metric showing that only 0.006% of page views use these dialogs in cross-origin iframes is misleading—just because users don’t hit a confirm dialog on every session doesn’t mean it’s not critically important when they do.

We’ve also seen games use alert() as a pause mechanism, leveraging its blocking nature intentionally. That’s a legitimate use case that disappears entirely.

The Proposed Workarounds Aren’t Good Enough

The suggested alternative for cross-origin iframes is postMessage: send the dialog content to the parent page and trigger it there. For a site like CodePen, that’s problematic for several reasons:

  • It breaks application flow. postMessage is asynchronous, while JavaScript dialogs block execution. Code that expects a true/false answer or a strict pause won’t work the same way.
  • It requires injecting code into user content. That’s new technical debt and can alter expected output—an extra <script> in someone’s HTML changes things like :nth-child selectors.
  • It’s a security risk. Passing user-generated content to a parent for execution opens up XSS vectors, however careful the implementation might be.

Lower-key suggestions like reassigning window.alert = console.log have essentially the same issues.

How Did We Get Here?

The response from the developer community has been sharply critical. Some have suggested a middle path—restrict the dialog to the iframe itself rather than showing it in the parent window, which would preserve functionality while improving UX. Others have argued that the deprecation process itself is the problem.

Chris Ferdinandi wrote about feeling condescended to when asking for clarification, noting that the message thread where this change was surfaced is full of developers begging Chrome not to proceed. Jeremy Keith pointed out that breaking changes are—and should be—rare on the web. If that changes, he argued, the web suffers in terms of predictability. He also noted that the burden shouldn’t be on developers to track which older features browser makers are planning to deprecate.

This isn’t an isolated complaint. The change was proposed in the WHATWG HTML repository, and the discussion is documented. We’re not opposed to improving the platform—the concerns about security and main-thread blocking are real—but the rollout has felt poorly handled. There are dialogs for more nuanced approaches, like iframe-localized dialogs or better sandboxing controls that already exist.

We’re generally fans of Google’s work pushing the web forward. But when the plan is to remove a fundamental part of the platform, the expectation should be far more developer outreach, far more conversation about implications and transitions, and far more willingness to adjust course. At the very least, the community deserves a better answer than “use postMessage” when the alternative doesn’t preserve the behavior a huge part of the web depends on.