[whatwg] Window and WindowProxy
Ian Hickson
ian at hixie.ch
Wed Aug 7 23:11:35 PDT 2013
On Wed, 7 Aug 2013, Boris Zbarsky wrote:
> On 8/7/13 5:18 PM, Ian Hickson wrote:
> > We could indeed move the indexed properties to WindowProxy, while
> > leaving the security checks (which apply to non-indexed properties
> > only) on Window. This would still address my concern, which is that if
> > we move the security checks to WindowProxy, and then break the
> > invariant whereby you can't actually get to a cross-origin Window
> > directly
>
> If we break that invariant, fwiw, then I suspect we have much bigger
> problems.
I would imagine most languages other than JavaScript would break that
invariant. What other problems would it break?
> Because the current spec effectively calls for the global to be a
> proxy-like object (or some sort of object that's not describable in ES
> spec terms at all, of course, but the idea of ES proxies is to be able
> to describe anything remotely sane).
No, the global object is the Window, at least per the spec today. Why is
this not accurate?
http://www.whatwg.org/specs/web-apps/current-work/#script's-global-object
> That's not actually compatible with ES because of how "var" needs to
> behave in global scope.
Could you elaborate on this?
> So it seems to me that any implementor trying to implement this spec
> will go to their favorite ES implementation and discover that the spec
> cannot be implemented as written and must instead be mapped to some
> other conceptual model. After thinking about it for a bit, the only
> obvious way to avoid having proxy-like behavior on the Window is to put
> it all on WindowProxy, which _already_ has proxy-like behavior no matter
> what.
I don't understand what mapping behaviour you think is conceptually needed
on Window.
> At which point, I think we should spec it that way, for two reasons:
>
> 1) It reduces the burden on implementors trying to understand this part
> of the spec and map it to what ES will let them do.
>
> 2) It reduces the likelihood that some modification to ES or the
> Window/WindowProxy specs will in fact make things unimplementable
> altogether in the future.
I agree that these are good goals.
> > The difficulty with moving just the indexed properties are that
> > "length" would now be on a different object than what it describes.
>
> I don't think that's a problem, honestly. "length" on a Window returns
> the number of child windows. An indexed access on a WindowProxy returns
> the corresponding child of its current Window. It seems fairly
> straightforward...
Straightforward isn't the word I would use, but ok.
> > Also, it would complicate the WindowProxy magic -- now, instead of it
> > just being a proxy, it would be a proxy except for certain properties.
>
> Indeed. Of course WindowProxy is already not "just a proxy": it doesn't
> transparently proxy enumeration or getOwnPropertyNames, for example.
It should act _exactly_ like Window. As far as I can tell, that means it
_should_ proxy "proxy enumeration" and getOwnPropertyNames, whatever those
are. Why do you think this is not the case?
> That's just not very clearly specified... Again, I think we should just
> clearly define the behavior of WindowProxy using the ES MOP primitives.
I have no idea what that means, but I'm certainly happy to do so if it
makes sense.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list