cancelBubble legacy property

[cvrebert]

UIEvent.cancelBubble works in all modern browsers.
Testcase: http://jsbin.com/jufexu/edit?html,css,js,output

Event.cancelBubble works in all modern browsers (Chrome, Safari, Edge, IE11) except Firefox.
Testcase: http://jsbin.com/wirelo/edit?html,js,output

To accurately reflect reality, I propose speccing at least one of these properties.

[annevk]

I think we should just define Event.cancelBubble then. Seems the shortest path towards interoperability and it's not really a big deal since it just reflects the stop propagation flag as far as I can tell.

@smaug----, objections?

[smaug----]

In Gecko UIEvent has that indeed and it sets the propagation stopped flag. This is really ancient stuff.
I thought we could have removed it, like to removed couple of similar properties few years ago.
IIRC, this is Netscapeism.

Looks like the property works in a bit different way in different browsers. In Gecko it maps to
stopPropagation() and you can effectively un-stopPropagation() with cancelBubble = false.
In Blink you can also cancel, but only cancelBubble = true, not stopPropagation().

[smaug----]

but yeah, ok to spec, although it is ancient bad API.

[annevk]

Hmm, yeah, in Blink's implementation this is its own primitive (and it seems you can set that back to false). Not sure we want it to be that complicated. @foolip, @RByers, thoughts?

[smaug----]

oh, it is also old IEism. Totally forgot. IE didn't use to have stopPropagation(), only cancelBubble

[RByers]

Our usage stats suggest that it's still pretty popular (though falling). This will be tainted somewhat by event copying code, but 4% of page views is huge compared to what we normally see for event copying (eg. 0.2% for webkitMovementX before we removed it). I Get a ton of hits for "cancelBubble" in httpArchive.

So yeah we're unlikely to be able to remove it. But if Gecko just has it mapped to stopPropagation then perhaps that would be web compatible for us (certainly simpler). What does Edge do? We might need to add UseCounters measuring how often the difference matters (eg. how often it's set back to false, or set from within capturing handlers while there are still other capturing handlers to run).

That said, if IE, Edge, WebKit and blink are all consistent here already, maybe it's best to just define it exactly as it's implemented in those browsers. I guess it's not completely crazy to think that some capturing handler may want to prevent all bubbling without preventing the rest of the capture or target phases.

@tkent-google any thoughts?

[foolip]

In Blink it's a separate internal slot, and used in two places:
https://chromium.googlesource.com/chromium/src/+/aede1d0909b3f905c74c769e610b903015f50569/third_party/WebKit/Source/core/events/EventDispatcher.cpp#179
https://chromium.googlesource.com/chromium/src/+/4e4da03f08faa602998125895ac4b884c60be001/third_party/WebKit/Source/modules/indexeddb/IDBEventDispatcher.cpp#36

@inexorabletash, any idea why there's special event dispatch code for IndexedDB?

If we end up having to specify something by the name cancelBubble it would be strange if it affected things outside the bubbling phase, but it might be worth measuring how often cancelBubble is actually set to true. @RByers, could you do a quick httparchive query to see how it's usually used to see if that's even worth investigating?

[annevk]

@foolip he mentioned in the above comment that there's a ton of hits.

[annevk]

Also, IndexedDB likely has special dispatch code because Blink's implementation of event paths is not generic I believe.

[foolip]

Ah, OK, then I change my question to "what do the hits look like"? I guess most of them set it to true because that's the only useful thing one can do with the API?

[smaug----]

FWIW, looks like there was code in Gecko which tried to allow changing cancelBubble flag only during target/bubble phase[1], but it was apparently never working, if I trust my own comment from 10 years ago https://bugzilla.mozilla.org/show_bug.cgi?id=330494#c3
(Gecko used to have super hard to maintain and understand event dispatch code before Gecko 1.9, so, around that 10 years ago.)

[1] I think this would be to mimic old IE. IIRC, it has effectively just target and bubble phases.

[RByers]

Ah, OK, then I change my question to "what do the hits look like"? I guess most of them set it to true because that's the only useful thing one can do with the API?

I'm swamped right now and can't dig in deeply, but here's the first 5000 results. Looks like jQuery, mootools some twitter libraries are major users. Want to spot check some of these and let us know what you find?

[foolip]

I opened 10 of them "at random" and took a quick look. Mostly it's used as a fallback when stopPropagation doesn't exist, but those cases wouldn't show up in use counter data.

In https://maps.googleapis.com/maps/api/js and http://w.sharethis.com/share5x/js/stcommon.2b05accc08f1ee42fe1983647ab923ea.js and multiple other scripts it's used together with stopPropagation which would show up in use counters but removing it probably wouldn't be observable.

In http://www.speedup.ir/angular/app/scripts/vendor/jquery.nicescroll.js there are many uses, most similar to the above but one that's gated on document.fireEvent:

      else if (document.fireEvent) {
        this.notifyScrollEvent = function(el) {
          var e = document.createEventObject();
          el.fireEvent("onscroll");
          e.cancelBubble = true; 
        };
      }

As long as Edge has removed document.fireEvent, that should be dead code everywhere.

In http://kolelnasmag.com/wp-content/themes/Fikra%20Mag3/js/uisearch.js there's an addEventListener polyfill which should also be dead code now.

In https://static.xx.fbcdn.net/rsrc.php/v2iaFb4/yH/l/en_US/0bcWBIJHikk.js @domenic makes an appearance :)

/**
 * @generated SignedSource<<4c94898b765e9ddb7bac02513e528723>>
 *
 * !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
 * !! This file is a check-in of a static_upstream project!      !!
 * !!                                                            !!
 * !! You should not modify this file directly. Instead:         !!
 * !! 1) Use `fjs use-upstream` to temporarily replace this with !!
 * !!    the latest version from upstream.                       !!
 * !! 2) Make your changes, test them, etc.                      !!
 * !! 3) Use `fjs push-upstream` to copy your changes back to    !!
 * !!    static_upstream.                                        !!
 * !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
 *
 * Copyright (c) 2012 Barnesandnoble.com, llc, Donavon West, and Domenic
 * Denicola

Anyway, in that file there's a bit of code that I saw in a few places, seems like this is the unminified code:
https://github.com/davidxi/js-code-study/blob/9b990abbf038e0195567b30c8da216498c23691b/src/Event.js

It looks like this isn't actually an Event but a custom EventObject so it shouldn't be a problem.

That was a very quick check, but I didn't see anyone setting cancelBubble to false and it seems plausible that mapping cancelBubble=true to stopPropagation() is web compatible, at least worth investigating.

[RByers]

From this description it sounds like we don't even know for sure that removing cancelBubble completely would be incompatible. Every browser has it, right? Is it work preparing a patch that uses a use counter to track whether cancelBubble actually as an impact (i.e. at bubbling time log if cancelBubble was used without stopPropagation being used redundantly), and using the telemetry cluster to look for examples in the top 10k?

Or is the cost of having it as an alias of stopPropagation low enough, and the compat risk sufficiently non-trivial that we should just do it?

[annevk]

If we could get away with making it an alias rather than its own primitive I think that'd be fantastic. Removing it altogether given the usage numbers seems rather risky.