W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2011

[whatwg] <base> elements, again

From: Adam Barth <w3c@adambarth.com>
Date: Mon, 24 Jan 2011 16:02:03 -0800
Message-ID: <AANLkTimjMqEw=eM2NF_Vu2Q3B5S3sbyNox4SyynLZrf3@mail.gmail.com>
On Mon, Jan 24, 2011 at 6:06 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> In https://bugzilla.mozilla.org/show_bug.cgi?id=627361 we have a page which
> has a subframe. ?The subframe has this HTML:
>
> ?<a href="javascript:do_default(0)">1261192</a>
>
> and near the end of the page has a <base target="_top">.
>
> In current Gecko builds, this fails, because we now allow <base> anywhere in
> the document per http://html5.org/tools/web-apps-tracker?from=5710&to=5711
> and hence the javascript: URI is run against the toplevel window, not the
> subframe's window, and there is no do_default function defined in the
> toplevel window.
>
> This presumably used to work in Gecko before we started trying to implement
> HTML5 <base> stuff because for <base> outside <head> we only applied it to
> <a> elements that came after the <base> when parsing.
>
> Why did/does this markup work in other UAs? ?Or does it not? ?Does the spec
> need changes here? ?As it stands, it's breaking existing markup.

In general, WebKit doesn't understand how to target JavaScript URLs at
other frames.  The basic limitation here is similar to why data URLs
in WebKit don't inherit the security origin of their creator.  I'd
like to change WebKit to match Gecko on both scores, but it's going to
require some delicate surgery.

Adam


> Note that we made the change to allow <base> anywhere about 10 days ago, and
> got this bug report within 6 days of making this change. ?So I have to
> assume that this is not an isolated incident, and that there are other pages
> like this out there. ?Especially because the broken page in this case is
> some sort of enterprise web app thing (Unicenter) which I assume is
> installed in more than one place.
>
> -Boris
>
Received on Monday, 24 January 2011 16:02:03 UTC

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