HTMLElement constructor step 5.2 refers to mysterious document

[dominiccooney]

I am trying to implement HTMLElement constructor in Blink. At step 5.2, the part that says “and node document set to document”, I don't know what document refers to.

I think this should follow the behavior of Image, which says: “The element's node document must be the active document of the browsing context of the Window object on which the interface object of the invoked constructor is found.”

Apologies in advance if I am missing something obvious here.

[domenic]

Thanks for the catch. I see two alternatives:

• (A) the active document of the browsing context of realm's global object (= the Window object on which the interface object of the invoked constructor is found)
• (B) realm's global object's newest Document object.

These will differ after navigation: if you saved the window.HTMLElement constructor of some iframe, then navigated the iframe, then register class extends SavedHTMLElement { } and new it up:

• (A) will create an element whose node document is the post-navigation document
• (B) will create an element whose node document is the pre-navigation document

Consistency with Image (and presumably Audio and other named constructors) probably means it's wisest to go with (A), although to me at least intuitively (B) makes more sense, both in terms of the actual outcome and in terms of it being a shorter path from realm.

Opinions @rniwa @annevk @smaug----?

[annevk]

Ideally the same as new Document(), new Text(), etc. Though DOM is a little vague for those: https://dom.spec.whatwg.org/#dom-document-document.

[domenic]

Yeah, DOM's "node document is the global object’s associated document" doesn't exactly define which global (incumbent, entry, current being the possibilities) but it's probably current, which would be (B).

(Note to self: I should probably clean up this constructor to use "the current Realm", instead of "GetFunctionRealm(the currently executing HTMLElement function)".)

I tested Image in http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4119 and it turns out that Chrome does (B) for both Image and Text, whereas Firefox does (A) for both Image and Text. Whereas per spec, Text is probably (B), and Image is (A).

So I think we have some flexibility here to fix custom elements and Image to match (B). Unless anyone objects, I'll make that change here (and PR DOM to increase clarity), then file some Firefox and Edge bugs.

[domenic]

BTW it would be good to merge #1091 to give me a solid basis for talking about this stuff in my fix.

[dominiccooney]

FWIW Blink implements the Text constructor like Image (in Blink bindings, this is governed by the ConstructorCallWith extended attribute.) We don't implement Document constructor yet, but will.

[annevk]

@bzbarsky the suggestion here is to make the associated document for new Text(), new Image(), new Document(), etc. the document associated with the current Realm's global object. As @domenic points out above this is what Chrome does, but not what Firefox does, and the specifications are a mixed bag at the moment.

[bzbarsky]

Er.. Firefox does in fact use the current Realm's newest document, option (B) above.

In the testcase at http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4119 the load in the iframe is same-origin, so when it completes the same Window is used for the new Document as far as I can tell (initial about:blank reuse stuff). In Firefox, when the Text constructor is called, it examines its current Realm global (the Window), gets its most recent document (doc2 in this case), and uses that as ownerDocument.

I modified Domenic's testcase to explicitly check whether the initial about:blank Window is being preserved and you can see the result at http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4120 -- it looks like Firefox is doing that and Chrome is not, which is why the rest of the behavior differs between them. I have no idea why Chrome is doing what it's doing there...

[bzbarsky]

Er, that testcase with a typo corrected: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4122

On http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4123 (click the button to run the test, yay popup blockers) Chrome seems to do the right thing with initial about:blank.

[bzbarsky]

And on http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4126 Firefox and Chrome also agree: both reuse the Window of the initial about:blank.

They also agree on http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4124 in that neither one reuses the initial about:blank Window there. I know why that happens in Firefox and I think we consider it a bug, but I'd have to step through the spec carefully to see what's specced for this case right now.

[domenic]

OK, so I didn't mean to get the initial about:blank involved; I forgot about the initial load.

http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4129 is a revised version, but still seems to show Chrome using (B) for both Image and Text, and Firefox using (A). (And, it still fails for weird seemingly-unrelated reasons in Edge.)

[bzbarsky]

http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4129 is identical to http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4119 except for the const log = w; bit and use of log instead of w. Did you mean to post some other link?

[domenic]

Yes, I meant to post something more like http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4134

This shows both Chrome and Firefox aligning on (B), it seems. There's some other different issue where setting and reading doc.name does not work in Firefox...

[bzbarsky]

This shows both Chrome and Firefox aligning on (B), it seems.

OK. I did tell you that Firefox does (B). ;)

There's some other different issue where setting and reading doc.name does not work in Firefox...

Please do feel free to link me to a testcase showing this problem. It doesn't seem to be showing up on http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4134 as far as I can tell.