1528791 - [Custom Elements] Firefox only web platform tests

Status: NEW

(Core :: DOM: Core & HTML, defect, P3)

Description

[David Burns :automatedtester]

The following tests are failing in Firefox but passing in Chrome and Safari

/custom-elements/Document-createElement.html [3 subtests]

Source: https://jgraham.github.io/wptdash/?bugComponent=core%3A%3Adom

Comment 1

[Boris Zbarsky [:bzbarsky]]

The test looks like this:

        return getDocument().then(function (doc) {
            class ElementWithAdoptCall extends HTMLElement {
                constructor()
                {
                    super();
                    doc.adoptNode(this);
                }
            };
            var name = 'element-with-adopt-call-' + testNumber;
            customElements.define(name, ElementWithAdoptCall);
            assert_true(new ElementWithAdoptCall instanceof ElementWithAdoptCall);

The prototype reparenting we do on adopt means that assert_true fails. We never reach the actual thing the test is trying to test (which we would pass if we reached it, afaict).

Anne, does the spec still allow that reparenting? That is, should this test be changed to work whether the reparenting happens or not?

Comment 2

[Anne (:annevk)]

Changing of prototypes by the user agent is not allowed, for any type of element. Previous discussion was at https://www.w3.org/Bugs/Public/show_bug.cgi?id=20567. There's an adoptedCallback that custom elements can use to implement this themselves, if needed (or deal with base URL changes and such).

We have some measurements in bug 928476 comment 14 about what this might leak, but unfortunately the cause of those leaks was not recorded, unless I'm missing something. If it's mostly document.open()-related it wouldn't have impacted other browsers and no longer impacts us.

Comment 3

[Hsin-Yi Tsai (she/her) [:hsinyi]]

We now have these per https://jgraham.github.io/wptdash/?bugComponent=core%3A%3Adom%3A+core+%26+html&paths=%2Fcustom-elements
▶ /custom-elements/CustomElementRegistry.html [3 subtests]
▶ /custom-elements/Document-createElement.html [3 subtests]
▶ /custom-elements/parser/parser-sets-attributes-and-children.html [1 subtests]
▶ /custom-elements/reactions/Document.html [1 subtests]
▶ /custom-elements/reactions/HTMLElement.html [3 subtests]

Comment 4

[Boris Zbarsky [:bzbarsky]]

/custom-elements/CustomElementRegistry.html [3 subtests]

This is because we use the LifecycleCallbacks dictionary to get callbacks off the prototype instead of the manual code described at https://html.spec.whatwg.org/multipage/custom-elements.html#dom-customelementregistry-define step 14.4.

There's a spec issue at https://github.com/whatwg/html/issues/3580 that hasn't gotten any movement, but Apple seemed supportive of changing to our behavior.

Note also that there are "disabledFeatures" tests here that Safari also fails, because neither WebKit nor Gecko implements that bit.

/custom-elements/Document-createElement.html [3 subtests]

See comment 1.

/custom-elements/parser/parser-sets-attributes-and-children.html [1 subtests]

This is failing the "HTML parser should call connectedCallback before appending child nodes." test. That seems like a legit bug to me; I am not aware of it being tracked so far.

/custom-elements/reactions/Document.html [1 subtests]

Something around execCommand; needs debugging.

/custom-elements/reactions/HTMLElement.html [3 subtests]

Two of these are around https://html.spec.whatwg.org/multipage/dom.html#the-translate-attribute which we don't implement reflection for. This test is testing reflection for it. I'm not aware of a bug for us implementing this.

The third one is the outerText thing being missing. That's because the test checks for 'outerText' in HTMLElement.prototype and we don't support that property. As the text notes, this property is non-standard; it really shouldn't be testing it as things stand. See https://github.com/whatwg/html/issues/668