[Bug 5850] JS global object

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5850





--- Comment #18 from Adam Barth <w3c@adambarth.com>  2008-07-19 09:18:58 ---
> It breaks down because the JS spec says it returns the global object, not the
> proxy.

I don't really see a way around this issue.  From test03.html:

document.body.innerHTML: Before... 
window.document.body.innerHTML: After... 
((function () { return this; })()).document.body.innerHTML: After... 
this.document.body.innerHTML: After... 

The first test pulls the document off the global object via the scope chain. 
The second goes via window (aka the window shell).  The third and fourth case
use "this" to get at "the global object," but they actually get the window
shell.  That means "this" isn't acting the same as the global object (i.e., the
object atop the scope chain).

> I don't want to specify something that says that "all the references now point
> to a different object". That's weird. It's the same object in every sense that
> you can check from script.

You mean that its the same object, except that all of its properties have
changed to reflect the new contents of the frame?

Another way to think about this behavior is the way that Mozilla thinks about
it.  In this view, there is one window/global object, but it is a "split"
object, with an inside and an outside.  As long the object is belongs is
currently occupying the frame, the two halves act as one.  After the frame
navigates, the object splits in two, with the outer half now attached to the
inner half of the new window/global object.  Most folks have pointers to the
outer half the object, so they now are talking to the new inner object.  Some
folks, like the scope chain, have pointers to the inner object and so they keep
referring to the same inner object.

There is another wrinkle to this whole business that might be worth considering
at the same time.  Suppose script in one frame has a pointer to the window
object of another frame, but the two frames are from different security
origins.  Not consider the the second frame (the one whose object this is)
modifies (e.g., replaces) a property of the window object that is visible
across domains (e.g., the "history" property).  Now the first frame (the one
from a foreign domain) tries to access this property.  What does it see?  There
are three possibilities:

1) It sees the modified object.
2) It sees the original object.
3) It sees some kind of error, like undefined.

Possibility (1) is a security vulnerability.  (I can explain more details if
you're interested.)  As I recall, (2) is the Firefox/Safari behavior and (3) is
the IE behavior.  I don't recall off-hand what Opera does in this case.

In Mozilla's split object way of thinking about the world, the cross-domain
frame sees the outer half the object which doesn't contain the modifications. 
(Of course, same-domain interrogators of the outer half will see the
modifications.)  In Safari, the actual global object (not the shell) just
appears to have different properties depending on who is asking.  (Literally,
they check the security descriptor and then either give a fixed answer or look
up the current state depending on how the access check turns out.)

I suspect none of this is allowed by the ECMAScript spec.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Saturday, 19 July 2008 09:19:34 UTC