Move HTMLDocument named getter to Document
Categories
(Core :: DOM: Core & HTML, task)
Tracking
()
People
(Reporter: e7358d9c, Unassigned)
References
(Blocks 1 open bug, )
Details
This is the last remaining non‑[ChromeOnly] feature exposed only on HTMLDocument.
|
||
Comment 1•5 years ago
•
|
||
This needs some careful testing to determine the "right" behavior. I just tried this testcase in Chrome and Safari:
<script>
var url = 'data:application/xml,<html xmlns="http://www.w3.org/1999/xhtml"><form name="x"/></html>';
var xhr = new XMLHttpRequest();
xhr.open("GET", url);
xhr.responseType = "document";
xhr.onload = function() {
alert(xhr.responseXML.x);
};
xhr.send();
</script>
and they both alert undefined just like Gecko does.
If I change the type in the data: URL to text/html, then Gecko and Safari alert [object HTMLFormElement] while Chrome continues to alert undefined.
Per spec, the named getter should work for an XHR response document, as far as I can see. But given that Document is [OverrideBuiltins], making the getter work when it didn't use to has major compat risks, so I think the spec might need to change here to match existing UA behaviors.
Apart from the web compat impact, there is a performance impact from making every Document a proxy. That said, I expect most Document property accesses happen on HTMLDocument instances... but that's just a gut feeling, not backed by data.
|
|
||
Comment 2•5 years ago
|
||
Another relevant testcase:
<?xml version="1.0"?>
<html xmlns="http://www.w3.org/1999/xhtml">
<form name="x"/>
<script>
alert(document.x);
</script>
</html>
When served as text/xml, this alerts undefined in all Firefox, Chrome, and Safari. Again, per spec, that's not what's supposed to happen.
|
|
||
Comment 3•5 years ago
•
|
||
From Blink's document.idl:
// Named getter is implemented without IDL code generation for better
// performance. See local_window_proxy.cc.
// getter object (DOMString name);
and the implementation is such that it only exposes named props for instances of the internal HTMLDocument class, and only ones that are being rendered in a Window (so not XHR response documents, for example). What it's doing is definitely not matching the HTML/IDL specs and can't even be expressed in those terms, as far as I can see.
I haven't dug into the WebKit code here yet.
|
|
||
Comment 4•5 years ago
|
||
What WebKit does is have an HTMLDocument interface that only has the named getter on it, which is exactly what Gecko does. See https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/html/HTMLDocument.idl.
Given that Blink also has an HTMLDocument interface (albeit without the named getter), I suspect we should just spec the current Gecko and WebKit behavior and mark this bug invalid. I filed https://github.com/whatwg/html/issues/4792.
I was going to file a Blink bug on their buggy behavior, but turns out I already did over 3 years ago: https://bugs.chromium.org/p/chromium/issues/detail?id=594008
This is looking less and less likely, and then there’s the [OverrideBuiltins] extended attribute, which I don’t want anywhere near XML5.
|
||
Updated•2 years ago
|
Description
•