On Mon, Oct 19, 2015 at 7:06 AM, Anne van Kesteren <ann...@annevk.nl> wrote:
> On Mon, Oct 19, 2015 at 8:06 AM, Bobby Holley <bhol...@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.