browser-compat-data icon indicating copy to clipboard operation
browser-compat-data copied to clipboard

Impossible for a machine to infer support for bubbling events

Open saschanaz opened this issue 3 years ago • 16 comments

#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)

saschanaz avatar Mar 11 '22 19:03 saschanaz

Removing bubbling events was done here first: https://github.com/mdn/browser-compat-data/pull/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.

Elchi3 avatar Mar 14 '22 13:03 Elchi3

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 avatar Mar 14 '22 14:03 saschanaz

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

saschanaz avatar Mar 14 '22 14:03 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)

saschanaz avatar Mar 14 '22 14:03 saschanaz

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.

queengooborg avatar Mar 15 '22 06:03 queengooborg

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

saschanaz avatar Mar 15 '22 08:03 saschanaz

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!

queengooborg avatar Mar 15 '22 08:03 queengooborg

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

  • api.GlobalEventHandlers.oncuechange (#13887)
  • api.Window.ongamepadconnected/disconnected (#14038)

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

saschanaz avatar Mar 15 '22 09:03 saschanaz

@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 https://github.com/w3c/webref/issues/593 for a possible approach.

foolip avatar May 05 '22 20:05 foolip

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.

saschanaz avatar May 05 '22 20:05 saschanaz

@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?

foolip avatar May 05 '22 20:05 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?

Yup.

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

I wouldn't call them useless given that those properties exist in browsers, at least from @types/web PoV. (Although I have to blame the spec editor who added it 😛)

saschanaz avatar May 05 '22 20:05 saschanaz

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

I wouldn't call them useless given that those properties exist in browsers, at least from @types/web PoV. (Although I have to blame the spec editor who added it 😛)

Since they can't be used to listen for any event that the browser can fire, it seems like a bad thing letting any developer know they exist via code completion or similar.

And I agree it was a spec mistake putting these on GlobalEventHandlers instead of HTMLMediaElement.

foolip avatar May 05 '22 21:05 foolip

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!

Note that this also applies to ShadowRoot#onslotchange (#16733).

saschanaz avatar Sep 17 '22 10:09 saschanaz

I think the need here is to know if code completion should suggest onabort when typing db.on... where db is an IDBDatabase, and similarly for type checkers.

This can indeed no longer be determined from BCD. Before it was possible because event entries were (sometimes) duplicated on the interfaces an event could bubble through.

To be overly precise, it wasn't possible before either to know if an event was bubbling, just that an event handler property existed. Take onfullscreenchange as an example, if BCD only represents that there is an onfullscreenchange property on Element and Document, that doesn't tell you whether the event is bubbling, or if it fires separately on both interfaces. (The answer is it fires on Document if the Element is no longer attached to the document.)

I think what's missing here is a machine-readable list of possible event paths, perhaps as a list of possible types get the parent for each interface. For Text this would be Element or DocumentFragment, for Document it would be Window, for SerialPort it would be Serial, etc.

Turns out that @webref/events might have just this, in the form of bubblingPath. I haven't looked at it myself, but @saschanaz have you checked out https://github.com/w3c/webref/tree/main/packages/events?

foolip avatar Sep 19 '22 13:09 foolip

Ah yes, I just remembered that there was https://github.com/openwebdocs/project/issues/61. I filed https://github.com/saschanaz/bcd-idl-mapper/issues/6.

saschanaz avatar Sep 19 '22 18:09 saschanaz