Window named properties shouldn't include some elements in non-HTML documents
Consider this testcase:
<html xmlns="http://www.w3.org/1999/xhtml">
<form name="foo"></form>
<div id="bar"></div>
<script>
onload = () => {
console.log(document.foo);
console.log(window.foo);
console.log(document.bar);
console.log(window.bar);
}
</script>
</html>
When loaded as HTML, it logs the HTMLFormElement twice, then undefined, then the HTMLDivElement, in both browsers and per spec.
When loaded as XHTML, it does the same thing as the HTML case in Firefox and the spec, and logs undefined four times in Chrome and Safari (because those browsers create an XMLDocument, not an HTMLDocument, for the XHTML MIME type??)
When loaded as XML (e.g. the text/xml MIME type), it logs undefined four times in all in browsers, but per spec the behavior should be the same as in the text/html case. That is, the named properties object in the spec does not have behavior depending on whether the document is an HTML document, but in browsers it does.
This is sort of similar to the fact the named getter on documents is HTML-document-only in implementations (see https://github.com/whatwg/html/issues/4792).
In concrete implementation terms, Gecko does https://searchfox.org/mozilla-central/rev/6bceafe72cad5d5752667b4b6bd595d3a4047ca3/dom/base/WindowNamedPropertiesHandler.cpp#117-121 which returns from the named properties object's [[GetOwnProperty]] without looking for either ids or names if the document is not HTML: in that case only child browsing contexts show up on the named properties object.
Blink looks like it has exactly the same sort of check at https://cs.chromium.org/chromium/src/third_party/blink/renderer/bindings/core/v8/custom/v8_window_custom.cc?l=271-274&rcl=2861890d85d275cfd2d055a72ebfe82851814bb7
@cdumez
Yes, in WebKit, we also only do this for HTML documents: https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/bindings/js/JSDOMWindowProperties.cpp#L65
Those properties are currently stored in a map in the HTMLDocument class, so we'd need to do a bit of refactoring to do this for all types of documents.
@cdumez Thank you for the link! I need to get better at digging around in trac...
Okay, so there's various questions here:
- Should the different document classes have different behavior. And in particular should only
HTMLDocumenthave named getters? (Seems like yes and yes?) - Should we use the
HTMLDocumentclass forapplication/xhtml+xml. (Firefox: yes, others: no. Seems like maybe?) - Should the global object care about the type of document class for its own named getter. (Seems like yes?)
Item 1 is mostly tracked by https://github.com/whatwg/html/issues/4792
This issue is mostly about item 3.
I hadn't even realized item 2 was a thing until I started writing testcases here. I was pretty surprised by the lack of interop there...