1586020 - Ordering of mixin inclusions in SVG and HTML IDLs do not match the spec

Status: NEW

(Core :: DOM: Bindings (WebIDL), task, P5)

Description

[Frédéric Wang (:fredw)]

Boris suggested it can be observable in terms of the property ordering.

See
https://html.spec.whatwg.org/multipage/dom.html#htmlelement (GlobalEventHandlers,
DocumentAndElementEventHandlers, ElementContentEditable, HTMLOrSVGElement)

https://svgwg.org/svg2-draft/types.html#InterfaceSVGElement ( GlobalEventHandlers, DocumentAndElementEventHandlers, SVGElementInstance, HTMLOrSVGElement)

VS

https://searchfox.org/mozilla-central/source/dom/webidl/HTMLElement.webidl ( GlobalEventHandlers, HTMLOrForeignElement, DocumentAndElementEventHandlers, ElementCSSInlineStyle, TouchEventHandlers, OnErrorEventHandlerForNodes)

https://searchfox.org/mozilla-central/source/dom/webidl/SVGElement.webidl (GlobalEventHandlers, HTMLOrForeignElement, DocumentAndElementEventHandlers, ElementCSSInlineStyle, TouchEventHandlers, OnErrorEventHandlerForNodes)

ElementCSSInlineStyle is defined in a separate CSS spec, so the ordering is not really specified: https://drafts.csswg.org/cssom/#the-elementcssinlinestyle-mixin

---

TouchEventHandlers seems to be a non-standard/legacy mixin?

OnErrorEventHandlerForNodes seems to be Mozilla-specific to workaround a bug in the spec. EventHandler has the following comment: "We think the spec is wrong here. See OnErrorEventHandlerForNodes/Window below."

Comment 1

[Boris Zbarsky [:bzbarsky]]

It turns out that the IDL declaration order is not observable in terms of property ordering in Gecko, because when we pull in properties from mixins we first sort the mixins by name: https://searchfox.org/mozilla-central/source/dom/bindings/parser/WebIDL.py#1114-1115

There are spec issues covering the fact that the web-facing behavior here is not defined: https://github.com/heycam/webidl/issues/473 and https://github.com/heycam/webidl/issues/432

TouchEventHandlers seems to be a non-standard/legacy mixin?

Yes.

OnErrorEventHandlerForNodes seems to be Mozilla-specific to workaround a bug in the spec.

Yeah, the spec has mostly fixed its bug here, but it requires examining the event's current target instead of just statically checking the handler type, which is what we do right now....

Comment 2

[ExE Boss]

This list now includes MathMLElement as of bug 1571487, where it was decided to be internally consistent and defer to this bug.

Comment 3

[Frédéric Wang (:fredw)]

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #1)

It turns out that the IDL declaration order is not observable in terms of property ordering in Gecko, because when we pull in properties from mixins we first sort the mixins by name: https://searchfox.org/mozilla-central/source/dom/bindings/parser/WebIDL.py#1114-1115

There are spec issues covering the fact that the web-facing behavior here is not defined: https://github.com/heycam/webidl/issues/473 and https://github.com/heycam/webidl/issues/432

Do we want to change the internal IDL declaration order, just to match the spec? Or are we waiting any decision there (seems discussion is leaning toward sorting keys, so that reordering does not matter)

OnErrorEventHandlerForNodes seems to be Mozilla-specific to workaround a bug in the spec.

Yeah, the spec has mostly fixed its bug here, but it requires examining the event's current target instead of just statically checking the handler type, which is what we do right now....

Is there an existing bug for that separate issue?

Comment 4

[Boris Zbarsky [:bzbarsky]]

Or are we waiting any decision there

I'd rather wait.

Is there an existing bug for that separate issue?

I am not aware of one. I also think the observable behavior for us and the spec is the same at this point; it's just the exact way it's implemented that's different...