This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html Multipage: http://www.whatwg.org/C#the-window-object Complete: http://www.whatwg.org/c#the-window-object Comment: Should Window's "document" property return the Window Posted from: 173.48.81.109 by bzbarsky@mit.edu User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20121213 Firefox/20.0
Silly comment form submitting itself early... What I meant to say was: Should Window's "document" property really return the document of the currently active Window in the browsing context, or should it return the Window's document (if any)? Seems to me like the latter would be preferable... Note, though, that this would mean that window.document and bareword "document" have slightly different behavior.
Having document and window.document be different seems confusing...
Yes, but having: <script> var doc = document; function f() { alert(doc == document); } </script> start alerting false at some point is just as confusing... Running script in navigated-from windows is just confusing; fact of life.
Why would it mean than window.document and document would have different behaviour? Bareword |document| is short for |this.document|; |window.document| is short for |this.window.document|. |this.window === this| always. |this| is a WindowProxy. Since WindowProxy always return the Window of the active Document, and you can't get a reference to a raw Window ever, as far as I can tell it doesn't matter whether Window.document returns the Window's document (that is, always the active Document's Window's Document), or whether it returns the active Document. They're the same thing.
> Bareword |document| is short for |this.document| As a matter of fact, it's not in implementations. Did you try it? The former does a lookup on the ES global (the Window) while the latter does a lookup on the WindowProxy. And they can't possibly be the same, note, because barewords are lookups on the scope chain, not on objects. You can see this most clearly in with blocks and inside inline event handlers, where converting bareword "foo" lookup to "this.foo" would give totally different behavior. I suggest you try testcases like the one in comment 3, where the frame containing that script is unloaded and then the function f is called, in some UAs to see how it behaves.
bz: Do you have a test case showing this? I haven't been able to construct a test case that contradicts comment 4 when the scope chain is otherwise uninteresting. (Note that the spec requires "If the script's global object is a Window object, then in JavaScript, the ThisBinding of the global execution context for this script must be the Window object's WindowProxy object, rather than the global object.")
There's a testcase in http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0328.html But let me attach it here too, just so you can play with it.
Created attachment 1328 [details] Subframe for testcase
Created attachment 1329 [details] Testcase You may have to save them both locally or put them on another server to test sanely because this Bugzilla is slightly HTML-attachment hostile.
Note also that the ThisBinding and the scope chain are totally separate concepts, for what that's worth.
Wow, I somehow was going through life assuming the ThisBinding was what was on the scope chain. Crazy. Sorry about that. Ok, looks like all the browsers agree that it should return the Window's document.
Checked in as WHATWG revision r7845. Check-in comment: Match reality better. (Turns out parts of the spec already assumed this was defined this way anyway.) http://html5.org/tools/web-apps-tracker?from=7844&to=7845
Checked in as WHATWG revision r7899. Check-in comment: Fix some typos or copypasta. http://html5.org/tools/web-apps-tracker?from=7898&to=7899