On Mon, Oct 19, 2015 at 7:06 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Mon, Oct 19, 2015 at 8:06 AM, Bobby Holley <bholley@mozilla.com> wrote:
> > 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).
>
> Ah yes. Would it make sense to simply make the "effective script
> origin" part of the keying tuple?
I think that would work, yes. In Gecko (and I suspect in other engines),
the cache just gets blown away each time document.domain changes. But since
you can never return to a previous effective script origin with
document.domain (you can only remove subdomains, not add them), this
shouldn't be observable.
> And I guess this "cache" is a
> WeakMap so the handed out functions can be GC'd?
>
Correct, though as with all WeakMaps this should never be observable.
> 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.
>
> Yeah, Window seems like a distinct problem since it already has a dual
> setup with WindowProxy and Window.
Sure, but I think it would be better to specify uniform behavior for
cross-origin objects without relying on the WindowProxy, if possible. In
Gecko's implementation, cross-origin object behavior is mostly orthogonal
to WindowProxy stuff.
> And it is not marked [Unforgeable]
> which means same-origin and cross-origin will differ quite a bit.
>
Between same-origin and cross-origin Window yes. But not between
cross-origin Window and cross-origin Location, which is why I'm suggesting
specifying those two things together.