On Sun, Nov 30, 2014 at 12:21 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> [ccing public-script-coord because I'm not sure what list is best for this;
> mostly I'm looking for feedback from other UA implementors.]
>
> We really need to create an actual specification for WindowProxy.  One of
> the serious problems is what to do with non-configurable properties.
>
> Consider this testcase (live version at
> http://web.mit.edu/bzbarsky/www/testcases/windowproxy/non-configurable-props-1.html
> with slightly different logging):
>
>   <iframe></iframe>
>   <script>
>   onload = function() {
>     var subframe = frames[0];
>     Object.defineProperty(subframe, "foo", { value: 1 });
>     console.log(Object.getOwnPropertyDescriptor(subframe, "foo"));
>
>     frames[0].frameElement.onload = function() {
>       console.log(Object.getOwnPropertyDescriptor(subframe, "foo"));
>     };
>
>     frames[0].location = "about:blank";
>   };
>   </script>
>
> The console in Firefox nightly and Chrome dev shows:
>
>   Object { configurable: false, enumerable: false, value: 1,
>            writable: false }
>   undefined
>
> The console in Safari 7 and WebKit nightly shows:
>
>   undefined
>   undefined
>
> The console in IE 11 shows:
>
>   [object Object]
>   undefined
>
> and if I examine the actual descriptor returned, .configurable is false.  No
> exceptions are thrown by any of the browsers.
>
> As I understand the ES spec, none of these browsers are enforcing the
> fundamental invariants: three of them because they have a non-configurable
> property go away and one because it silently doesn't define a
> non-configurable property when you try to do it.
>
> Though the Safari behavior is actually quite interesting.
> http://web.mit.edu/bzbarsky/www/testcases/windowproxy/non-configurable-props-2.html
> shows that if the property is defined from inside the subframe then
> getOwnPropertyDescriptor does not see it from the outside, even though from
> the inside it's visible.  And
> http://web.mit.edu/bzbarsky/www/testcases/windowproxy/non-configurable-props-3.html
> shows that when defining from "outside" the property _is_ in fact being
> defined as far as scripts "inside" are concerned.
>
> Oh, and getting .foo from "outside" returns 1, but doing
> getOwnPropertyDescriptor up the proto chain of "subframe" consistently
> returns undefined in Safari.
>
> This last bit has nothing to do with configurability, by the way
> Object.getOwnPropertyDescriptor returns undefined from the "outside" in
> general in Safari.
>
> Per spec ES6, it seems to me like attempting to define a non-configurable
> property on a WindowProxy should throw and getting a property descriptor for
> a non-configurable property that got defined on the Window (e.g. via "var")
> should report it as configurable.

Yes, both of these conclusions are correct.


>  But that matches precisely 0 UAs.... and
> throwing seems like a compat worry.  :(
>
> Anyway, what are reasonable behaviors here?  What are UAs willing to align
> on?

The only reasonable behavior that I see is the one you specified.
Introducing an invariant violation of this sort would kill these
invariants in general, as the Proxy target mechanism relies on these
invariants to enforce that Proxies cannot introduce more violations.

Put another way, if this invariant is preserved by WindowProxy, then
anyone else seeking to create another object that violates this
invariant can create a Proxy whose target is a WindowProxy. Its
violation enables further violations. The invariants are inductive. A
violation breaks the induction.

>From prior similar experiences, the way to get this fixed quickly is
to add test262 tests which fail on these violations. All browsers have
been much quicker to fix breakage that shows up in test262 results
than to mere bug reports.


>
> -Boris
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



-- 
    Cheers,
    --MarkM

On Sun, Nov 30, 2014 at 12:21 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> Per spec ES6, it seems to me like attempting to define a non-configurable
> property on a WindowProxy should throw and getting a property descriptor for
> a non-configurable property that got defined on the Window (e.g. via "var")
> should report it as configurable.

Yes, both of these conclusions are correct.


>  But that matches precisely 0 UAs.... and
> throwing seems like a compat worry.  :(
>
> Anyway, what are reasonable behaviors here?  What are UAs willing to align
> on?

The only reasonable behavior that I see is the one you specified.
Introducing an invariant violation of this sort would kill these
invariants in general, as the Proxy target mechanism relies on these
invariants to enforce that Proxies cannot introduce more violations.

Put another way, if this invariant is preserved by WindowProxy, then
anyone else seeking to create another object that violates this
invariant can create a Proxy whose target is a WindowProxy. Its
violation enables further violations. The invariants are inductive. A
violation breaks the induction.

From prior similar experiences, the way to get this fixed quickly is
to add test262 tests which fail on these violations. All browsers have
been much quicker to fix breakage that shows up in test262 results
than to mere bug reports.

On Sun, Nov 30, 2014 at 12:21 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> Per spec ES6, it seems to me like attempting to define a non-configurable
> property on a WindowProxy should throw and getting a property descriptor for
> a non-configurable property that got defined on the Window (e.g. via "var")
> should report it as configurable.

Yes, both of these conclusions are correct.


>  But that matches precisely 0 UAs.... and
> throwing seems like a compat worry.  :(
>
> Anyway, what are reasonable behaviors here?  What are UAs willing to align
> on?

The only reasonable behavior that I see is the one you specified.
Introducing an invariant violation of this sort would kill these
invariants in general, as the Proxy target mechanism relies on these
invariants to enforce that Proxies cannot introduce more violations.

Put another way, if this invariant is preserved by WindowProxy, then
anyone else seeking to create another object that violates this
invariant can create a Proxy whose target is a WindowProxy. Its
violation enables further violations. The invariants are inductive. A
violation breaks the induction.

>From prior similar experiences, the way to get this fixed quickly is

to add test262 tests which fail on these violations. All browsers have
been much quicker to fix breakage that shows up in test262 results
than to mere bug reports.