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

On Tue, Oct 13, 2015 at 6:15 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 10/13/15 2:31 AM, Anne van Kesteren wrote:
>
>> On Mon, Oct 12, 2015 at 6:43 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>>
>>> You don't even need to do that.  You just return WindowProxy or Window or
>>> whatever, and Location.  The cases when you need to return a cross-origin
>>> thing will only happen via cross-origin access of some sort, so that's
>>> the
>>> place where you'll define wrapping in the cross-origin thing...
>>>
>>
>> What does that mean, concretely?
>>
>
> I'd have to look up exactly how the cross-origin things work (which really
> means Bobby should be in this conversation).
>

To be clear, there's no concept of 'wrapping' in the cross-origin spec.
Instead, the spec talks about 'minting' a fresh per-origin object to
represent a 'concept' [1] (Window or Location).

>From the spec:

 When a script from one origin tries to get a Window or Location object
> representing a concept from another origin, it gets an instance of that
> object that is specially minted for that origin.
>

Effectively, this means that the implementation maintains a map of
|(scriptOrigin, concept) -> observedObject|, where |scriptOrigin| is the
origin of the script observing the stuff, |concept| is the underlying
window or location being represented, and |observedObject| is the object
that the script actually sees.

In 99% of the cases, |scriptOrigin == concept.origin|, which is the
non-cross-origin case. There is a very small set of methods and getters
(like HTMLIFrameElement.contentWindow) that might return a concept where
|scriptOrigin != concept.origin|, which is the cross-origin case. It's up
to the implementation whether to add special map-checking logic to those
places (abarth's preference for chromium at the time), or to put it
somewhere in the bindings such that it happens automatically (like Gecko
does it).

Oh, and it's not quite clear to me what happens when you have a
>>> used-to-be-same-origin WindowProxy become cross-origin on navigation. I
>>> assumes that's defined somewhere in the relevant spec bit...
>>>
>>
>> That's defined?
>> https://old.etherpad-mozilla.org/html5-cross-origin-objects does not
>> mention it.
>>
>
> Then that needs fixing.  Again, Bobby needs to be in this conversation.
> ccing him.
>

That was mostly outside the scope of the cross-origin object summit, IIRC.
We defined things in terms of Window, not WindowProxy, and assumed that
WindowProxy would do its magic and forward somehow. Note that WindowProxy
is another one of those access points that might give you a reference
(implicitly) to a cross-origin object.

bholley

[1] The word 'concept' was Hixie's or abarths (I forget which), and I'm
personally fine with changing it if it's objectionable.