Reflection of global bindings

David Bruant bruant.d at gmail.com
Mon Dec 17 06:19:15 PST 2012


Le 17/12/2012 13:51, Mark S. Miller a écrit :
> 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.
I agree on the silent+note solution.
For web-compat sake and to conform to the non-deletable properties 
convention, global var/function "should" be reflected as configurable: 
false. The only reason configurable:true is on the table is for 
WindowProxy self-hostability, no need to pollute all globals of all 
environment for that reason.

> 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.
Just an adjustement: "no non-configurable properties *except 
[Unforgeable] 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.
I remember a slideshow where someone had written (and presented to 
others!) that in JavaScript, memory could be saved by using the "delete" 
operator on variables. I'm willing to bet that some content on the web 
relies on 'delete' silently failing on global var-declared variables.
If that was the case, then changing var/function globals to be deletable 
would break the web.

>> 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.
I'm hopeless on this point.
I assume that cases where a script holds a reference to an 
iframe.contentWindow and the iframe at src changes are too numerous to hope 
for a change.

David


More information about the es-discuss mailing list