v148 · removal · platform hygiene

Deprecate and remove non-allowlisted Event interfaces

Chrome's document.createEvent("Foo") factory historically accepted dozens of legacy interface names. Many of those produced events that didn't behave like real DOM events. This change drops everything that isn't on the modern allowlist — older callers fall back to the standard Event constructor instead.

concepts

  1. createEvent Factory Roll Call

    Probe every historical event factory name in your browser. Which ones still return a real Event, which throw, which return a stub — a one-page bill of health for legacy event construction.

  2. Modern Constructors

    Side-by-side: the legacy createEvent() + initEvent() recipe versus the typed constructor (new CustomEvent(), new MouseEvent(), etc). Pick an event type, fire both, and inspect the resulting Event objects.

  3. Migration Guide

    Paste your JavaScript and this tool scans for all document.createEvent() calls, identifies deprecated interface names removed in Chrome 148, and suggests the modern Event constructor equivalent for each with a live browser compatibility test.

  4. Event Migration Scanner

    Paste code and click Scan to find every document.createEvent() call. For each call: is the interface allowlisted in Chrome 148? What is the modern replacement? An Auto-fix button rewrites deprecated calls. A full compatibility matrix covers all 30 event interfaces and their Chrome 148 status.

  5. Allowlist Reference

    Complete table of all 31 historical createEvent() interface names showing Chrome 148 status (ALLOWLISTED or REMOVED), the modern constructor replacement, and a live "Try it" button that probes each interface in your current browser. Filter by status and search by name.

why it shipped

Modern code constructs events via new CustomEvent("foo") or new Event("bar"). The legacy document.createEvent("...") factory pre-dates those constructors and accepts a surprisingly wide set of names — "PopStateEvent", "HashChangeEvent", even "SVGZoomEvents". Most of those names don't map to a well-defined behaviour, they bloat the platform, and they are vanishingly rarely used. Chrome 148 trims the set to what the HTML spec actually requires and drops the rest; the resulting interfaces are smaller and easier to maintain.

references

implementation reference

Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗