Intent to Deprecate and Remove: Deprecate and remove: non-allowlisted Event interfaces from document.createEvent()

[Chromestatus]

Contact emails

soosu...@gmail.com, zi...@chromium.org

Explainer

No information provided

Specification

https://dom.spec.whatwg.org/#dom-document-createevent

Summary

Remove support for creating non-allowlisted event interfaces from document.createEvent(). After this change, these will throw NOT_SUPPORTED_ERR as required by the specification.

Blink component

Blink>DOM

Web Feature ID

No information provided

Motivation

The DOM spec defines an allow-list for createEvent(), but Chrome also supports interfaces not on this list: - AnimationEvent - Usage : 0(https://chromestatus.com/metrics/feature/timeline/popularity/1162) - CloseEvent - Usage : 0(https://chromestatus.com/metrics/feature/timeline/popularity/1227) - ErrorEvent - Usage : 0(https://chromestatus.com/metrics/feature/timeline/popularity/1170) - IDBVersionChangeEvent - Usage : 0(https://chromestatus.com/metrics/feature/timeline/popularity/1201) - KeyboardEvents - Usage : 0.00003(https://chromestatus.com/metrics/feature/timeline/popularity/1228) - PageTransitionEvent - Usage : 0(https://chromestatus.com/metrics/feature/timeline/popularity/1174) - PopStateEvent - Usage : 0.000007(https://chromestatus.com/metrics/feature/timeline/popularity/1176) - TrackEvent - Usage : 0(https://chromestatus.com/metrics/feature/timeline/popularity/1186) - TransitionEvent - Usage : 0.012334(https://chromestatus.com/metrics/feature/timeline/popularity/1183) - WebGLContextEvent - Usage : 0(https://chromestatus.com/metrics/feature/timeline/popularity/1224) - WheelEvent - Usage : 0.000011(https://chromestatus.com/metrics/feature/timeline/popularity/1184) These interfaces lack init*Event() methods, making the created events unusable. Event constructors can be used instead (e.g., new AnimationEvent()).

Initial public proposal

No information provided

Debuggability

No information provided

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/41228793

Estimated milestones

DevTrial on desktop	146
DevTrial on Android	146

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5095987863486464?gate=6283297569243136

This intent message was generated by Chrome Platform Status.

[Yoav Weiss (@Shopify)]

I believe we'd need some more information about the compatibility and interoperability risks with this.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69982e7e.710a0220.1e5fb2.0081.GAE%40google.com.

[David Baron]

It looks like all of the usage numbers are negligible (less than 1 in 2 million page loads, i.e., less than 0.00005%) except for TransitionEvent, which is around 0.01% of page loads (1 in ten thousand).  Do you know anything about the usage of TransitionEvent?  Is it for feature detection?

-David

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJJXuX1tYg%2BBs%2BzxWqGT-bEasBab3d2fKcXn80F35q8pg%40mail.gmail.com.

[soosungp33 via Chromestatus]

1) compatibility and interoperability risks Firefox has removed all of them, and WebKit has removed all events except KeyboardEvents, PopStateEvent, and WheelEvent. Reference: https://wpt.fyi/results/dom/nodes/Document-createEvent.https.html?label=master&label=experimental&product=chrome&product=firefox&product=safari&aligned&q=chrome%3A%21pass There have been previous discussions in Chromium: - https://groups.google.com/a/chromium.org/g/blink-dev/c/BkPSl0Oey8k/m/kZZ_GR9VAAAJ - https://groups.google.com/a/chromium.org/g/blink-dev/c/bj1SUohzcR4/m/5SXyG3kbBAAJ In summary, for interfaces without init*Event() methods, the recommendation is to use constructors instead of createEvent. Therefore, I believe it should be fine to deprecate and remove events that are not in the current spec [1] and have low usage. [1] https://dom.spec.whatwg.org/#dom-document-createevent 2) information on TransitionEvent usage I looked into some usage cases of TransitionEvent: - https://github.com/search?q=document.createEvent%28%27TransitionEvent%27%29%3B&type=code It appears that most usage is in Angular legacy code or older websites, and is mostly being used for feature detection. However, since the usage is above 0.01%, there seems to be some risk. So how about only deprecating TransitionEvent while removing the other events? Note that TransitionEvent is not currently in a deprecated state (no warning is shown when used). - yeonghan

[soosungp33 via Chromestatus]

I forgot to say this earlier..! Late, but thanks for your interest in my intent!

[Alex Russell]

Are most of these non-allowlisted Event types new-able? That is, can you cons them up via constructor?

[soosungp33 via Chromestatus]

Yes, they can be created. You can verify with the test below. - https://jsfiddle.net/5Lr0cdgx/

[Alex Russell]

Thanks, that's helpful.

[Yoav Weiss (@Shopify)]

Can you confirm that this change would be behind a feature flag?

[Rick Byers]

What makes you say there's no initEvent? Eg. this code seems to work today:

let ke = document.createEvent("KeyboardEvent")
ke.initEvent("keydown")
ke.type
>  'keydown'

Even with the low use counter, given that this works today I wouldn't be surprised if some old Enterprise LOB app relies on this somewhere, in which case we need to follow the process for making Enterprise-friendly breaking changes. This used to be the only way to create events, so unfortunately I don't think we can consider this as zero compat risk.

Rick

--

[YeongHan Kim]

Yes, I plan to use a feature flag so that it will not be removed before sufficient testing is completed, following the guideline.
https://www.chromium.org/blink/launching-features/#deprecate

Thank you.

- yeonghan

2026년 2월 26일 목요일 AM 1시 12분 26초 UTC+9에 yoav...@chromium.org님이 작성:

[YeongHan Kim]

You are right. I think my previous explanation was insufficient and I apologize for the confusion. I have now updated chromestatus with more detailed information.

In addition, events with 0 usage will be removed, and events with low usage but still carrying risk, including KeyboardEvents, will be deprecated without remove.

The status and risk of each individual event are summarized in the sheet below. Please refer to it.

Reference: https://docs.google.com/spreadsheets/d/1z3UP34xP0BDSOr5kINyMfBnPC1IdqrquJMtt806wuRM/edit?usp=sharing

Thank you.

2026년 2월 26일 목요일 AM 1시 23분 18초 UTC+9에 rby...@chromium.org님이 작성:

[Philip Jägenstedt]

Hi Yeonghan,

We discussed this in the API owners meeting today (present: Daniel, Yoav, Chris, Vlad, Dan, Mike, Alex, me) and we think makes sense to remove these in M148, without deprecation period:

AnimationEvent
CloseEvent
ErrorEvent
IDBVersionChangeEvent
PageTransitionEvent
TrackEvent
WebGLContextEvent
PopStateEvent
WheelEvent

The last two have non-zero usage, but it's still incredibly low.

Please use a flag for this group so that we can revert it with Finch if necessary.

For KeyboardEvent, the risk seems slightly higher because it could be used together with initKeyboardEvent() in old code, from the time that this was the only supported way to create an initialize such events.

For TransitionEvent, the usage is a bit high (~0.01%) so it makes sense to be more careful.

So, for KeyboardEvent and TransitionEvent, we'd like to see them deprecated for 3 milestones before removal in M151.

If you're happy with this approach, LGTM1.

Best regards,

Philip

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ac2cd874-344d-433a-9fcc-58b5f2bf8ae2n%40chromium.org.

[YeongHan Kim]

Hi! First of all, thanks for your interest!

I have no objections to the discussion points. I'll proceed as you suggested.
Thanks!

- Yeonghan

2026년 3월 5일 목요일 AM 1시 28분 11초 UTC+9에 Philip Jägenstedt님이 작성: