[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.  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?

-Boris

[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):

```html
   <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.  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?