Le 17/12/2012 13:51, Mark S. Miller a écrit :
On Mon, Dec 17, 2012 at 4:26 AM, Andreas Rossberg <[email protected]> wrote:
On 17 December 2012 13:01, Mark S. Miller <[email protected]> wrote:
On Mon, Dec 17, 2012 at 2:03 AM, Andreas Rossberg <[email protected]> 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@src changes are too numerous to hope
for a change.
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
