On Feb 19, 2009, at 1:20 AM, David-Sarah Hopwood wrote:
Ian Hickson wrote:
On Tue, 17 Feb 2009, Mark S. Miller wrote:
I don't understand. If the object you're calling Window is
inaccessible
from ES code, and if the object you're calling WindowProxy forwards
everything to your Window, why not just relabel Window ->
InternalWindow, WindowProxy -> Window?
I don't really mind what the objects are called, the point is just
that
the object at the top of the scope chain is not the same as the
object
returned by "this" (or "window" on the global object).
MarkM's point is that *given that the object called Window is
inaccessible*,
there's no way to observe that the object called Window is at the
top of
the scope chain. An implementation could reflect all property changes
in that object to the object called WindowProxy, by some unspecified
mechanism (which is allowed since they are both host objects).
It is possible to observe that the object at the top of the scope
chain behaves differently than the global "this" value (it may have an
entirely different set of properties), so this arguably violates the
ECMAScript requirement that these be the same object, even though
object identity cannot be observed directly.
However, this can only be observed in the presence of multiple global
objects and global object replacement via navigation, which is a
situation not adequately covered by the ECMAScript spec at present.
One could make the case that because the difference is not observable
under a single global object, then the behavior is conforming.
I'm confused by the motivation of the change in HTML5. It seems like
it is
imposing most of the complexity that would be needed to fix some of
the
security problems associated with the global object, *without*
actually
fixing those problems.
The HTML5 spec behavior does fix important security problems, relative
to what older browsers used to do. Older behavior was to reuse the
same global object across navigations, but simply clear the variables.
This creates easily exploitable XSS vulnerabiliites. Note though that
HTML5 is following the implementations here rather than leading.
Also, it is a breach of standards development etiquette for the HTML
WG to
make a a change (even in a draft) that it believes to be
incompatible with
the ECMAScript spec, without consulting TC39. It should not have
been left
to you in the role of an implementor to point out the incompatibility.
I think Ian discharged his obligation by notifying TC39 of the issue
and starting this discussion. At this point, the important thing is to
come up with a solution we can agree on.
Regards,
Maciej
_______________________________________________
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
