Add GlobalEventHandlers.beforexrselect_event

[Elchi3]

Companion PR for mdn/content#15376

Discussion: #7545 (comment) and ff.

[Elchi3]

fwiw, the alternative would be to add this under the specific interfaces:

api.Document.beforexrselect_event
api.Window.beforexrselect_event
api.HTMLElement.beforexrselect_event
api.SVGElement.beforexrselect_event
api.MathMLElement.beforexrselect_event

[foolip]

As argued in mdn/content#15376 (comment), I think this should go under api.Element.beforexselect_event.

[Elchi3]

@saschanaz would api.Element.beforexrselect_event work for you even if the IDLs don't install it under Element?

[Elchi3]

Also @queengooborg, would this work with the collector? Would you remap this to Element somehow?

[queengooborg]

Yes, this would be remapped to the Element API by the collector already, as the collector demixes all mixins before generating tests!

Edit: this will also map to Document, HTMLElement, and anything else that "implements GlobalEventHandlers;" in IDL!

[saschanaz]

Also @queengooborg, would this work with the collector? Would you remap this to Element somehow?

My current logic check two places: The original mixin or each interface. It would be hard to find Document.onbeforexrselect when it's in Element since it's not an ancestor of Document. (I should fix the logic even if it was an ancestor though)

But theoretically it can still be somehow tracked as it has GlobalEventHandlers anyway, I should gather all the interfaces and check the support data exists anywhere, although that's kinda weird since there may or may not exist multiple support data or not.

[foolip]

Yes, this would be remapped to the Element API by the collector already, as the collector demixes all mixins before generating tests!

For anything in GlobalEventHandlers, the collector will generate the tests for HTMLElement+SVGElement+MathMLElement, but not Element. The reason there's also a test on Element in the collector is https://github.com/foolip/mdn-bcd-collector/blob/main/custom-idl/dom-overlays.idl, but that's the exception, not the rule.

The problem we have here is that GlobalEventHandlers adds event handler attributes everywhere, but in documentation we want to be specific about where events fire.

The *_event entries might be on both a more general interface like Element because they can fire, or at least bubble through, any kind of Element. They might also be on a more specific interface like HTMLVideoElement because they only fire on that specific kind of element.

I think that a mapping would have treat all kinds of elements as one class, all kind of documents as one class, and also know whether a specific event bubbles. The bubbling information is currently not machine readable anywhere, but maybe a decent approximation is to guess that all events bubble.

[github-actions]

This pull request has merge conflicts that must be resolved before it can be merged.

[queengooborg]

Thanks @Elchi3! However, we ended up deciding to demix GlobalEventHandlers as it's the only mixin left and it's not fully representative of what events fire on what interfaces.

[Elchi3]

Thanks @Elchi3! However, we ended up deciding to demix GlobalEventHandlers as it's the only mixin left and it's not fully representative of what events fire on what interfaces.

okay, thanks! How should I add beforexrselect to BCD now?

fwiw, the alternative would be to add this under the specific interfaces:

api.Document.beforexrselect_event
api.Window.beforexrselect_event
api.HTMLElement.beforexrselect_event
api.SVGElement.beforexrselect_event
api.MathMLElement.beforexrselect_event

^ like this?