html icon indicating copy to clipboard operation
html copied to clipboard

Window named properties shouldn't include some elements in non-HTML documents

Open bzbarsky opened this issue 6 years ago • 5 comments

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

bzbarsky avatar Dec 16 '19 17:12 bzbarsky

@cdumez

rniwa avatar Dec 16 '19 22:12 rniwa

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 avatar Dec 16 '19 22:12 cdumez

@cdumez Thank you for the link! I need to get better at digging around in trac...

bzbarsky avatar Dec 17 '19 03:12 bzbarsky

Okay, so there's various questions here:

  1. Should the different document classes have different behavior. And in particular should only HTMLDocument have named getters? (Seems like yes and yes?)
  2. Should we use the HTMLDocument class for application/xhtml+xml. (Firefox: yes, others: no. Seems like maybe?)
  3. Should the global object care about the type of document class for its own named getter. (Seems like yes?)

annevk avatar Jan 10 '20 14:01 annevk

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...

bzbarsky avatar Jan 10 '20 16:01 bzbarsky