Spec for document.close() doesn't seem to match UAs very well

[bzbarsky]

Consider this testcase:

var doc = new DOMParser().parseFromString("<div><span>aaa", "text/html");
doc.addEventListener("load", () => console.log("LOAD"));
doc.addEventListener("DOMContentLoaded", () => console.log("DOMContentLoaded"));
doc.open();
console.log(doc.readyState);
doc.write("aaa");
console.log(doc.readyState);
doc.close();
console.log(doc.readyState);

I would expect this to log "loading", "loading", "loading" (or maybe "interactive"), then log "DOMContentLoaded".

That's because open() sets the readiness to "loading" and then close() does not change it, so the only way readiness would change is from https://html.spec.whatwg.org/multipage/parsing.html#the-end step 1 or 7.1. It's possible that close() triggers step 1 there, but 7.1 is defined to happen async. And 4.1 is also defined to happen, hence the "DOMContentLoaded" log.

What I see in Chrome is:

loading
loading
complete

and nothing else. What I see in Safari is:

loading
loading
interactive

(and the state never transitions to "complete" afaict).

@TimothyGu @domenic @annevk

[bzbarsky]

Ah, I was adding the listener too early. DOMContentLoaded is fired, but sync under close(), looks like? At least in Chrome and Safari.

For the similar testcase when the document is in an iframe, both Chrome and Safari synchronously transition to "complete" when close() is called, fwiw. Firefox seems to be the only one doing sort of what the spec says in that case.

[domenic]

I remember this being declared a bit out of scope in #3818:

load event in conjunction with document.close() (web-platform-tests/wpt#10239)

Resolution: This seems to be a bit out of scope for an investigation focused on document.open(), as it touches navigation as well as iframe loading behavior. Keep existing spec for now, and revisit in the future in the context of a comprehensive iframe investigation.

Still, it would indeed be good if someone were able to come up with a more interoperable definition for document.close(); hopefully it'll be much less work than document.open().

[domenic]

I guess another issue here is that given

For each shadow-including inclusive descendant node of document, erase all event listeners and handlers given node.

It's predictable that "load" and "DOMContentLoaded" will never be logged, because those event listeners get erased.

[domenic]

web-platform-tests/wpt#10844 is also related; web-platform-tests/wpt#12727 is a subset that only tests document.open() behavior (no close) and got merged, but 10844 remains open with some close-related tests.

[TimothyGu]

Basically, this is https://crbug.com/878491.

[bzbarsky]

It's predictable that "load" and "DOMContentLoaded" will never be logged

Right, hence "I was adding the listener too early". Adding the listeners after the open() call shows the interop issues.

Is there a chance of that Chrome bug getting fixed? To allow off-thread parsing it would be best if close() did not have normative sync behavior of any sort for things that can't happen until end of parsing (e.g. the readyState change and the DOMContentLoaded firing).

[bzbarsky]

(And to be clear, I am still investigating the various test fallout from implementing the spec's document.open behavior in Gecko, and the firing of the load event is one of the big issues; this used to be handled automatically-ish by the navigation-like behavior of open(). I need to implement it somehow, but I am trying to figure out what the actual behavior is going to need to be.)