Re: Figuring out the behavior of WindowProxy in the face of non-configurable properties

On Thu, 15 Jan 2015, Yehuda Katz wrote:
> 
> If it's available to JavaScript consumers it must look like an object 
> that obeys ES invariants to JavaScript consumers. No (new, ugh) 
> exceptions.

This isn't a new exception. It predates the invariants by years.


On Wed, 14 Jan 2015, Filip Pizlo wrote:
> 
> Are you saying that it’s easier to spec having the browser find all 
> variables (local or otherwise) that reference some object and replace 
> them with references to a different object?

Easier than what?

What I'm proposing is the following text, which has been in the spec for 
years: "all operations that would be performed on it must be performed on 
the Window object of the browsing context's active document instead"

It doesn't talk about finding variables or anything, though it's 
isomorphic with doing that in practice, and talking about WindowProxy 
objects as if they were assigned to variables whose values changed is 
easier for me to describe to authors than the forwarding behaviour.


On Wed, 14 Jan 2015, Boris Zbarsky wrote:
> 
> My point is that no sane implementation would possibly want to actually 
> implement it that way

It's what IE does, according to Travis.


> > If there is any behaviour that is underdefined by the HTML spec's 
> > current prose, please tell me, so that I can spec it.
> 
> Care to ask the UA implementors who are clearly not doing anything even 
> resembling your spec?  Because it might turn out they might have reasons 
> for it...

I've asked you many times.


> > Well it predates all the ES6 stuff we're talking about here by several 
> > years
> 
> All the "stuff" involved was in ES5.  It's not new in ES6.  I've also 
> pointed this out to you several times now.

I don't really care about the version number. The HTML side of this dates 
back to the ES3 days.


> > it doesn't leave anything undefined.
> 
> Implementations seem to disagree by their actions, sadly.

Implementations disagreeing with each other doesn't mean the spec is 
undefined. It's at least as common for the implementations to just not 
match the spec.


> > I also disagree that what the spec says doesn't match implementations.
> 
> Uh... Have you _tried_ testing this stuff in Safari?  I have; please see 
> archives for the results.  They look nothing like your spec.

It doesn't match _all_ implementations, certainly.


On Wed, 14 Jan 2015, Mark S. Miller wrote:
> 
> WindowProxy is however a first class value observable by JS code

My point is that it's not. WindowProxy can literally not be observed. You 
can only ever observe the Window it points to, and the only way to tell 
that it changes Window is through circumstancial evidence (e.g. the 
properties change).


> Neither does the magic replacement theory excuse it from violating the 
> spec.

Based on when the spec prose was written, the ES spec is violating the 
HTML spec here, not vice versa.


> The ES5 constraints on updating non configurable properties are eternal 
> invariants.

Yes. Nothing here is violating these invariants. The invariants apply to 
the Window object.


> by writing test2c, in the same spirit as test2a and test2b:
> 
> (function(){"use strict";
> 
> // assume "gopd" & "is" initialization runs first, so these are
> // the original functions.
> var gopd = Object.getOwnPropertyDescriptor;
> var is = Object.is;
> 
> function test2c(obj, name, interleave) {
>   name = String(name);
>   var desc1 = gopd(obj, name);
>   interleave();
>   var desc2 = gopd(obj, name);
>   if (!desc1.configurable) {
>     assertFalse(desc2.configurable);
>     assertTrue(desc2.enumerable === desc2.enumerable);
>     if (gopd(desc1, 'writable') && !desc1.writable) {
>       assertFalse(desc2.writable);
>       assertTrue(is(desc1.value, desc2.value));
>     }
>   }
> }
> 
> return test2c;
> 
> }());
> 
> In a conforming ES6 implementation (or a conforming ES5 one given the 
> std "is" polyfill), it must not be possible to call test2c such that 
> these asserts fail. No where do these specs say "unless interleave() 
> replaces all pointers to obj to point at a different object". If it did, 
> the whole notion of eternal invariants would be nonsense.

Per the HTML spec, there's two ways that WindowProxy can change. One is 
session history traversal. That can never happen with JS on the stack, so 
it can't violate your example above.

The other is document.open(). Behaviour around that is less interoperable, 
and the current behaviour of replacing the singletons might be something 
we can change, I dunno. From my understanding of what Travis described, IE 
behaves exactly like the spec says, which would cause the above to assert 
false. Firefox certainly does currently:

   http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3369

Chrome and Safari don't seem to replace the Window when you do 
document.open(), which seems likely to be the source of bugs. I'm 
surprised I haven't noticed it before. I would have assumed pages would 
depend on the previous document's fiddling with Window to be removed.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'