Re: Defining exotic objects in IDL, HTML, or both?

On Sun, Oct 18, 2015 at 4:22 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Fri, Oct 16, 2015 at 10:45 PM, Bobby Holley <bholley@mozilla.com>
> wrote:
> > On Fri, Oct 16, 2015 at 12:58 PM, Anne van Kesteren <annevk@annevk.nl>
> > wrote:
> >> Hmm. One problem with the proposed design (assuming we're not defining
> >> compartments in the specification) is that it overrides === which TC39
> >> would not be happy with. Not having to do that would be preferable I
> >> think. === works fine for Window since there's WindowProxy. It seems
> >> like Location would need something similar.
> >
> > It may, at least conceptually, but I'm kind of loathe to do that just for
> > document.domain.
> >
> > Basically, the one piece of magical behavior here is that, when Document
> a
> > grabs a reference |x| to cross-origin Document b's location, and then
> both
> > Documents become same-origin via Document.domain, |x| suddenly points to
> the
> > now-accessible b.location. Furthermore, any method pulled off of |x|
> before
> > a given change in document.domain retains its distinct identity.
> >
> > This is all nasty and document.domain-specific, so it really sucks to
> > complicate the spec model further on its account. But maybe it can't be
> > helped.
>
> It does seem that if we are to specify Location in terms of ECMAScript
> and, as you said elsewhere, the separate cross-origin objects are not
> actually observable since [[Set]] throws, we could maybe get away with
> a simpler model. Where the internal methods of the object simply
> branch on same-origin vs cross-origin and then do the right thing.
>

Hm, you may be right that this is the sanest way to make this
ES-compatible, especially if the observables are the same (I can't think of
any contradictions at the moment, but my brain is tired right now). We
still need minting for the functions, and we need to clear those cached
functions every time document.domain is set. But with that I think it
should work (but again, tired).


>
> E.g., [[GetPrototypeOf]] would return null when cross-origin, but
> would return the Location prototype object when same-origin. And since
> Location is marked [Unforgeable] it doesn't even have much of a
> prototype object to speak of. Everything interesting are own
> properties.
>

Well, there's still the stuff on Window, which begs the question of the
behavior here, but that's probably fine if we do the proxy thing. In the
cross-origin case Window.close is an own property, in the same-origin case
it lives on the prototype.


> I realize this does not match what Adam Barth wanted, but it does seem
> to preserve the invariants from the Etherpad while also resulting in a
> sane specification that adheres to the invariants valued by
> ECMAScript/TC39. And since it should have the same observable outcome
> (unless I missed something, which I might well have) in terms of tests
> and behavior, everyone can still keep their respective implementation
> strategies.
>

I think I agree, but please keep me in the loop on how this is progressing
in case something else pops up out of my memory. Thanks for working on this
Anne!

bholley