This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27502 - Create a more rigorous spec for the same-origin WindowProxy object
Summary: Create a more rigorous spec for the same-origin WindowProxy object
Status: RESOLVED MOVED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Macintosh All
: P2 normal
Target Milestone: 2013 Q1
Assignee: Anne
QA Contact: contributor
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-03 20:25 UTC by Boris Zbarsky
Modified: 2016-02-11 16:18 UTC (History)
10 users (show)

See Also:

Attachments

Description Boris Zbarsky 2014-12-03 20:25:57 UTC 
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?
Comment 1 Domenic Denicola 2014-12-03 20:45:07 UTC 
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, ...?
Comment 2 Boris Zbarsky 2014-12-03 20:48:23 UTC 
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...
Comment 3 Boris Zbarsky 2014-12-03 20:49:48 UTC 
Oh, and this is still ignoring some of the complications around the interaction with "this", but those would need to live in ES anyway.
Comment 4 Domenic Denicola 2014-12-03 20:51:48 UTC 
Sounds good. I'll spend a bit of time on it sometime in the late-this-week/early-next-week continuum.
Comment 5 Ian 'Hixie' Hickson 2014-12-03 23:45:48 UTC 
I don't see why 2-5 can't just do the same as it would on the Window object directly.
Comment 7 Domenic Denicola 2014-12-12 21:39:55 UTC 
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
Comment 8 Ian 'Hixie' Hickson 2015-01-30 16:03:58 UTC 
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.
Comment 9 Anne 2015-01-30 16:25:17 UTC 
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.
Comment 10 Allen Wirfs-Brock 2015-01-30 17:35:56 UTC 
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.