Reflection of global bindings
Mark S. Miller
erights at google.com
Mon Dec 17 04:51:17 PST 2012
On Mon, Dec 17, 2012 at 4:26 AM, Andreas Rossberg <rossberg at google.com> wrote:
> On 17 December 2012 13:01, Mark S. Miller <erights at google.com> wrote:
>> On Mon, Dec 17, 2012 at 2:03 AM, Andreas Rossberg <rossberg at google.com> wrote:
>>> I see the following preferable solutions to deal with DOM features violating ES:
>>> 1. Lobby to fix the DOM and make it conform to ES instead of the other
>>> way round. Alex Russell has argued for this repeatedly.
>>> 2. Where we can't (sadly, probably most cases), and are forced to
>>> codify existing DOM hacks in ES, isolate these hacks as much as
>>> possible. Specifically, in the current case, define them as specifics
>>> of the global object (the global object is a lost cause anyway).
>> In general, I might be fine with that approach. But because of direct
>> proxies, it doesn't work for invariant enforcement. Direct proxies can
>> use the presence of a single invariant-violating object to create any
>> number of other invariant-violating objects.
> Yes, but is that a different problem than the global object itself?
> Why would you expect anything else? And how would introducing an extra
> set of internal attributes help?
Sorry, too much context. I agree about not specifying a new set of
internal attributes. I only mean that the WindowProxy must be
specified (on the HTML side) so that it doesn't violate these
invariants. Regarding the need for these properties to refuse being
configured, that seems adequately handled with prose in both ES and
HTML, without needing to introduce formal new internal attributes. The
ES spec could be silent (with a note) on whether these properties are
reported as non-configurable, so that non-browser environments without
a WindowProxy don't need to reproduce this insanity.
The sanity check everyone should continue to use is whether the
WindowProxy behavior could be self-hosted using direct proxies. In
this case, the WindowProxy would need to use the shadow proxy
technique. The real target is the hidden window, and the shadow target
(the one the proxy itself knows directly) has no non-configurable
properties. The handler refuses to configure any property that is
non-configurable on the real target, while continuing to report all
these properties as configurable.
An easier solution that would be fine with me is for these "var" and
"function" variables to actually be configurable, so that we don't
need this odd behavior at all. Brendan is right that this is a
breaking change. But is it an important one? I don't know. But it
doesn't hurt any integrity issue I care about.
> Of course, I personally wouldn't mind being radical and simply forbid
> proxying the global object altogether. But I assume that you are going
> to say that there are important use cases. :)
Independent of these specific issues, I think that the whole Window vs
WindowProxy hack is terrible. If anyone thinks there is any hope of
getting rid of this hack, I encourage you to try.
More information about the es-discuss