You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
... and are in a document tree with window's browsing context's active document as their root;
and the third bullet point has the same wording.
This seems like a problem if bareword references don't get routed through the WindowProxy (which I think they shouldn't be and generally aren't for things like "var" and other things directly defined in ES). Specifically, consider this testcase:
<iframe srcdoc="<script>function f() { return abc }</script><div id=abc>"></iframe>
<script>
var f;
onload = () => { f = frames[0].f }
</script>
<button type="button" onclick="alert(f())">
Inspect the value.
</button>
<button type="button"
onclick="document.querySelector('iframe').srcdoc = '<span id=abc>'">
Change the doc
</button>
Click the "inspect" button, then the "change the doc" button, then the "inspect" button again.
What should happen when clicking the "inspect" button the second time? Per the text of the spec, the HTMLSpanElement should be alerted, because the spec is using the browsing context's active document, not the Window's associated document. Safari TP (I'm told) and Firefox alert the HTMLDivElement instead (use the Window's associated document). Chrome throws a ReferenceError for the "abc" property being undefined.
But what would happen if the navigation were to a different origin? I don't have a testcase ready to hand, but I would really hope none of the browsers would fetch the cross-origin element. Yet that is precisely what the spec requires to happen, if the bareword get is not routed via WindowProxy. If it is, presumably the WindowProxy would throw a security exception.
I would suggest that we align on the Firefox and Safari TP behavior here: just use the Window's associated document.
Under https://html.spec.whatwg.org/multipage/window-object.html#named-access-on-the-window-object in the bullet list of the Window's supported property names (no obvious way to link it directly) the second bullet says:
and the third bullet point has the same wording.
This seems like a problem if bareword references don't get routed through the WindowProxy (which I think they shouldn't be and generally aren't for things like "var" and other things directly defined in ES). Specifically, consider this testcase:
What should happen when clicking the "inspect" button the second time? Per the text of the spec, the HTMLSpanElement should be alerted, because the spec is using the browsing context's active document, not the Window's associated document. Safari TP (I'm told) and Firefox alert the HTMLDivElement instead (use the Window's associated document). Chrome throws a ReferenceError for the "abc" property being undefined.
But what would happen if the navigation were to a different origin? I don't have a testcase ready to hand, but I would really hope none of the browsers would fetch the cross-origin element. Yet that is precisely what the spec requires to happen, if the bareword get is not routed via WindowProxy. If it is, presumably the WindowProxy would throw a security exception.
I would suggest that we align on the Firefox and Safari TP behavior here: just use the Window's associated document.
@annevk @domenic @rniwa
The text was updated successfully, but these errors were encountered: