Intent to Ship: Non-composed Mouse and Pointer enter/leave events

Skip to first unread message

Mustaq Ahmed

May 24, 2023, 1:48:14 PM5/24/23
to blink-dev

Contact emails



Make the event.composed property in mouseenter, mouseleave, pointerenter and pointerleave events "false" to be spec compliant and to fix interop gaps. Both the UI Events spec for Mouse Events and the Pointer Events spec define these events as non-composed. Both specs switched away from their original definitions few years ago: In addition to addressing the interop gap, this change also fixes an erroneous double/triple dispatch of these events to a shadow DOM host in Chromium when the shadow DOM also listens to the event (

Blink component


TAG review


TAG review status

Not applicable



This fixes a well-known interop gap.


The risk is negligible because Mozilla shipped the feature 5 years ago. Some prominent websites were updated back then, thanks to Mozilla's outreach ( The compat risk is non-zero because Chromium has always dispatched these events as composed.

Gecko: Shipped/Shipping (

WebKit: Shipped/Shipping (

Web developers: Positive ( --- this is a 5-star dev reported bug).

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?



No special change needed here: DevTools console and event listener breakpoints support investigating all event attributes.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?


Is this feature fully tested by web-platform-tests?


Requires code in //chrome?


Tracking bug

Sample links

Estimated milestones

Shipping on desktop116
Shipping on Android116
Shipping on WebView116

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).


Link to entry on the Chrome Platform Status

This intent message was generated by Chrome Platform Status.

Rick Byers

May 31, 2023, 11:26:20 AM5/31/23
to Mustaq Ahmed, blink-dev
Thanks for improving interop here Mustaq!

It looks like this is behind an experimental RuntimeEnabledFeature "NonComposedEnterLeaveEvents", which I assume you'll just set to 'stable' once approved, right? That way if we do discover any breakage, we can flip the kill-switch and do a full compat analysis / breaking change plan, right? I tend to agree the compat risk is very low and we can think of this just as a minor bug-fix. I don't see any easy way to measure the compat risk quantifiably. 


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
To view this discussion on the web visit

Chris Harrelson

May 31, 2023, 11:52:18 AM5/31/23
to Rick Byers, Mustaq Ahmed, blink-dev

Daniel Bratell

May 31, 2023, 11:55:37 AM5/31/23
to Chris Harrelson, Rick Byers, Mustaq Ahmed, blink-dev

Mustaq Ahmed

May 31, 2023, 1:27:48 PM5/31/23
to Rick Byers, Chris Harrelson, Daniel Bratell, blink-dev
Thanks for improving interop here Mustaq!

An update on the Interop front: most of the WPTs resolved by this change are part of Interop 2023, and today's score on the dashboard confirms a 10+ points improvement (from 71.5 to 82) to our Interop 2023 Pointer/Mouse score:

Rick Byers

May 31, 2023, 1:39:46 PM5/31/23
to Mustaq Ahmed, Chris Harrelson, Daniel Bratell, blink-dev
Awesome, great to see Mustaq. Thanks for the follow-up!
Reply all
Reply to author
0 new messages