Impossible for a machine to infer support for bubbling events

[saschanaz]

#15006 caused https://github.com/microsoft/TypeScript-DOM-lib-generator/pull/1284/files#r825015464, where IDBDatabase.onabort support is now unable to be inferred from BCD.

Basically BCD is removing all data for bubbling events, and there's no machine-readable data about which events bubbles to which interfaces, AFAICT.

(And this is again a logical breaking change: #12250)

[Elchi3]

Removing bubbling events was done here first: #13925.
Basically, @foolip and I figured that we don't need separate data points for the same event.

I think we need to better understand your requirements on machine-readability of BCD to avoid this and other issues from appearing.

[saschanaz]

I need a way for types/web to read browser support for all attributes including the event handlers. I see no way to read the support of IDBDatabase.onabort in bcd 4.0.8+, and there's no way to infer this from other data point. (In other words, I can't just look at BCD and learn that IDBDatabase.onabort is related to IDBTransaction.onabort.)

[saschanaz]

(I wonder how @foolip and @queengooborg dealt with this in their bcd tool?)

[saschanaz]

(Random idea: It might be useful to have data about event bubbling (perhaps in a separate package) to implement a linter to prevent contributors from adding them again)

[queengooborg]

We don't actually handle event specifics like bubbling in the mdn-bcd-collector, so I can't really give any advice on this. As it is right now, the collector is only testing support for the event handlers on the specific interfaces that implement them, and not child or parent interfaces.

[saschanaz]

But IDBDatabase is not a parent of anything in terms of inheritance, isn't it?

[queengooborg]

I did some digging into IDBDatabase, and wrote a comment on the related PR (#15006) stating why I think those subfeatures shouldn't have been removed -- hope that helps!

[saschanaz]

Thanks! I guess that also applies to the followings because there are relevant attributes, right?

• api.GlobalEventHandlers.oncuechange (Single event entries for TextTrack APIs #13887)
• api.Window.ongamepadconnected/disconnected (Conform gamepad Window events to new style; update Chromium versions #14038)

Edit: Well, those two are actually inferrable from _event counterpart and interfaces using the mixins.

[foolip]

@saschanaz was there every any machine readable information about whether an event bubbles and which interfaces it would bubble through? For example, how does a machine infer that a "connect" event fired on SerialPort bubbles to Serial and that in fact no "connect" event is ever fired with Serial as the target? The mere presence of onconnect on both interfaces doesn't contain this information, and that's what BCD had before.

I've filed w3c/webref#593 for a possible approach.

[saschanaz]

The mere presence of onconnect on both interfaces doesn't contain this information, and that's what BCD had before.

That mere presence works, because types-web does not really care about the bubbling itself. The bubbling info only becomes important as BCD uses it as a reason to remove existing data, and then types-web has no way to infer the data source as such reason is only visible to humans.

[foolip]

@saschanaz I see, so the problem you're trying to solve is starting from @webref/idl, which of the EventHandler attributes are supported by two or more major browser engines and should be included?

Do you also want to drop skip the useless properties like window.onvolumechange for events that actually don't bubble?