On 10/13/15 2:31 AM, Anne van Kesteren wrote:
On Mon, Oct 12, 2015 at 6:43 PM, Boris Zbarsky <bzbar...@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).
Yeah, that and self[0], which is defined as an indexed getter that
returns a WindowProxy at the moment.
Ah, good point. So fwiw, I still think that we should move the
[integer] stuff to the WindowProxy directly. I've said this a few
times, and it would make it easier to define custom behavior like this
for it. If we want iterability, we'd have to define that by hand
instead of relying on the IDL definition for indexed getters... but we
want that anyway, because we want to be iterating the WindowProxy, not
the Window.
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.
So I thought about it a bit more, and WindowProxy may in fact need to be
in IDL in some way, no matte what. That depends on what we want to
happen with arguments when a Window/WindowProxy is passed in and in
particular on whether the callee should just store a WindowProxy or
operate on a Window somehow. See prior discussion in
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27128#c9 and
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27128#c13
-Boris
