This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
See discussion in bug 27128. This is about same WindowProxy for a same-origin Window; for cross-origin Window the current proposal is at https://etherpad.mozilla.org/html5-cross-origin-objects My general proposal is as follows: 1) WindowProxy forwards most of its MOP operations directly to its current window. 2) [[GetOwnProperty]] claims all props are configurable. 3) [[DefineOwnProperty]] throws if the provided descriptor has configurable:false, otherwise forwards it along. 4) [[IsExtensible]] returns true. 5) [[PreventExtension]] does nothing and returns false. 6) Web IDL is changed to check branding on the current Window instead of the WindowProxy in cases when the "this" object is a WindowProxy. I think that should pin down the behavior pretty much compeletely. Anything I'm missing here? Domenic, are you interested in trying to spec this, or should I give it a shot?
Heh, this seems almost too easy... > Domenic, are you interested in trying to spec this, or should I give it a shot? I'd be willing to do a first draft in .txt or Markdown, but honestly having to convert this into HTML (or XML if it ends up in WebIDL) pushes it over the edge into "no fun." So ... maybe? Not sure where you planned to put this---WebIDL, HTML, ...?
Oh, and the reflection of WindowProxy in Web IDL will just be the JS object involved, just like "object" but with an extra check that the object you have is in fact a WindowProxy. I think a draft in markdown or text form would be a great start. As for where to put this, I'm leaning toward Web IDL, given the Web IDL bits we need here...
Oh, and this is still ignoring some of the complications around the interaction with "this", but those would need to live in ES anyway.
Sounds good. I'll spend a bit of time on it sometime in the late-this-week/early-next-week continuum.
I don't see why 2-5 can't just do the same as it would on the Window object directly.
Because that would violate http://people.mozilla.org/~jorendorff/es6-draft.html#sec-invariants-of-the-essential-internal-methods
Sketch up at https://github.com/domenic/window-proxy-spec with a couple open issues capturing the Web IDL stuff I wasn't as such how to approach: https://github.com/domenic/window-proxy-spec/issues
I don't agree with comment 6 on two levels. First, it doesn't actually violate the constraints. The constraints apply to the Window objects, which honour them; you can't tell if the WindowProxy object honours them, because you have no way to actually query a WindowProxy. Second, even if the invariants were violated, I have no problem with them being violated. WindowProxy predates them; we should not have introduced them if they are violated by WindowProxy. I strongly believe that the proposal here is adding quirks and weirdness to the Web platform that are confusing and unnecessary. If we went this route it would just contribute further to the weirdness that people dislike about the Web platform.
All objects conform to a set of invariants. We find out (late in the game, but shit happens) that Window/WindowProxy are problematic with respect to those invariants. We come up with a solution that browsers are willing to go for. And you argue that by doing that we are introducing weirdness. I would argue the exact opposite, we are removing it.
I wonder if the root of this disagreement is a difference of what is meant by "object"? Does the HTML platform actually have a formally specified object model that defines the precise semantics of something that is an "object"? The lack of it, would explain why there currently are the platform "weirdnesses" that have been mentioned. Without a specification there is no way to decided whether some particular behavior of a platform "object" is normal or weird. A formally specified object model is one of the foundations of the ECMAScript specification. Pretty much everything else builds upon it. ECMAScript lit5erally has no way to talk about anything that is neither a primitive data type nor a conforming object. If there is no such HTML platform object specification, then I suggest adoption of the ECMAScript object model. It would give you something solid to stand upon.
https://github.com/whatwg/html/pull/638