W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2012

Re: [whatwg] Proposal: location.parentOrigin

From: Tobie Langel <tobie.langel@gmail.com>
Date: Tue, 20 Nov 2012 08:27:47 +0100
Message-ID: <CAMK=o4cgLn4sV3vyfY7kX9SrpeRhtcpjJzaNq7Br+hATE3Cvng@mail.gmail.com>
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.:


and to check whether it came from the same origin (sugar around
window.getOrigin(otherWindow) == window.getOrigin(window)):


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.


[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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:48 UTC