- From: Tobie Langel <tobie.langel@gmail.com>
- Date: Tue, 20 Nov 2012 08:27:47 +0100
- To: Ian Hickson <ian@hixie.ch>
- Cc: whatwg <whatwg@lists.whatwg.org>, Michal Zalewski <lcamtuf@coredump.cx>, Adam Barth <w3c@adambarth.com>, Malte Ubl <malte.ubl@gmail.com>, Jonas Sicking <jonas@sicking.cc>
On Tue, Nov 20, 2012 at 6:47 AM, Ian Hickson <ian@hixie.ch> wrote:
> On Mon, 26 Mar 2012, Adam Barth wrote:
>>
>> For nested browsing contexts, expose the origin of the parent browsing
>> context via location.parentOrigin. (For non-nested browsing context,
>> the property would null.)
>
> This ended up implemented in WebKit as Location.ancestorOrigins(), a
> method that returns a static DOMStringList with the origins of the
> ancestor browsing contexts in reverse order (top-level browsing context
> last, parent browsing context first). It doesn't respect sandboxing.
This API is painful to use and doesn't contain any info for
window.opener or sibling browsing contexts (see WebKit bug[1] and
related discussion on G+[2]) which makes it useless for some of the
use cases.
A better API would allow to get the origin of a referenced browsing
context, e.g.:
window.getOrigin(otherWindow);
and to check whether it came from the same origin (sugar around
window.getOrigin(otherWindow) == window.getOrigin(window)):
window.isSameOrigin(otherWindow);
That said, one of the key use cases for this API is to code around a
Webkit bug[3] so maybe that should be fixed first.
--tobie
---
[1]: https://bugs.webkit.org/show_bug.cgi?id=83493
[2]: https://plus.google.com/116910304844117268718/posts/QyHfGL9GBd5
[3]: https://bugs.webkit.org/show_bug.cgi?id=43504
Received on Tuesday, 20 November 2012 09:19:36 UTC