Intent to Deprecate and Remove: setting Event.cancelBubble to false

49 views
Skip to first unread message

Peiyong

unread,
Jan 19, 2017, 5:09:34 PM1/19/17
to blink-dev

Primary eng emails

l...@chromium.org


Summary

Make Event.cancelBubble=false a no-op.


Motivation

According to https://github.com/whatwg/dom/issues/211, setting cancelBubble to true is considered as an alias to stopPropagation(), and https://dom.spec.whatwg.org/#dom-event-cancelbubble indicates setting cancelBubble to false should do nothing.


Compatibility And Interoperability Risk

No. UseCounter is indicating very low usage.


Firefox[0] and Safari[1] have already changed the behavior to meet the spec, bug was filed on Edge's side[2].


[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1324380

[1] https://bugs.webkit.org/show_bug.cgi?id=166018

[2] https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/10266390/


Alternative implementation suggestion for web developers

None.


Usage information from UseCounter

https://www.chromestatus.com/metrics/feature/timeline/popularity/1348 indicates it's rare that cancelBubble actually changes which callbacks are invoked.

https://www.chromestatus.com/metrics/feature/timeline/popularity/1349 indicates it's likely common to change cancelBubble from false to true.

https://www.chromestatus.com/metrics/feature/timeline/popularity/1350 indicates it's super rare to change cancelBubble to false.


So, it's safe to make Event.cancelBubble=true an alias to stopPropagation() and Event.cancelBubble=false a no-op.


OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=675549


Entry on the feature dashboard

We don't have an entry on the feature dashboard.


Requesting approval to remove too?

Yes.


Philip Jägenstedt

unread,
Jan 19, 2017, 6:07:21 PM1/19/17
to Peiyong, blink-dev
It's very encouraging to see this has already changed in Gecko and WebKit, minor changes like this often have a tendency to drag on for years. LGTM1, but please do add a chromestatus.com entry for this change.

Rick Byers

unread,
Jan 23, 2017, 1:12:28 PM1/23/17
to Philip Jägenstedt, Peiyong, blink-dev
LGTM2

Rick Byers

unread,
Jan 23, 2017, 1:22:06 PM1/23/17
to Philip Jägenstedt, Peiyong, blink-dev
I should say that I think the only real question here is whether we should have a deprecation message for a milestone or not.

I checked the internal UseCounter data.  It's also essentially zero (0.00002% - just enough non-zero to prove the counter is working at all).  Given other browsers have long behaved this way and the unlikelyhood of anyone actually depending on the semantics, I'm fine with skipping the deprecation period.  Though it certainly wouldn't hurt if anyone feels differently.

Chris Harrelson

unread,
Jan 23, 2017, 1:31:55 PM1/23/17
to Rick Byers, Philip Jägenstedt, Peiyong, blink-dev
LGTM3

--
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+unsubscribe@chromium.org.

Reply all
Reply to author
Forward
0 new messages