W3C home > Mailing lists > Public > www-archive@w3.org > October 2015

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

From: Bobby Holley <bholley@mozilla.com>
Date: Mon, 19 Oct 2015 13:24:12 -0700
Message-ID: <CAKBxTcJtTogKTnTo_C_kTNTriJ1PxXz5WWkR==3dyXfzzhz38w@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Bobby Holley <bholley@mozilla.com>, Boris Zbarsky <bzbarsky@mit.edu>, Domenic Denicola <d@domenic.me>, Cameron McCormack <cam@mcc.id.au>, www-archive <www-archive@w3.org>
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.
Received on Monday, 19 October 2015 20:25:00 UTC

This archive was generated by hypermail 2.3.1 : Monday, 19 October 2015 20:25:01 UTC