[webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses

[David Levin]

Suppose I am using a framework does window.frameElement for various
reasons. When that framework is used in an iframe, it causes errors to
appear in the console.

For example, suppose the framework does this:

var a;
try {
    a = window.frameElement; // WebKit outputs a console error here.
    if (!a)
        return;
} catch (e) {
    return;
}
...


Now if I had this new method, I would change the framework to do this:

var a;
try {
    // WebKit doesn't throw an exception for x-origin parent access, but it
will puts errors in the console.
    // Do an explicit access check to avoid having the error appear in the
console.
    var canAccessParent = window.parent.webkitCanAccess;
    if (canAccessParent != undefined && !canAccessParent)
        return;
    a = window.frameElement;
    if (!a)
        return;
} catch (e) {
    return;
}
...


Does that help? (The use case is about avoiding spurious console error
messages, so console error messages are real errors.)

dave


On Thu, Mar 22, 2012 at 8:44 PM, Sam Weinig <weinig at apple.com> wrote:

> Hey Dave,
>
> Can you describe the use case for this new property?  When would an author
> use it?
>
> -Sam
>
> On Mar 22, 2012, at 4:16 PM, David Levin <levin at chromium.org> wrote:
>
> Resurrecting a really old thread so continue the conversation now that I'm
> hitting this issue :).
>
> On Mon, Aug 16, 2010 at 2:16 PM, Sam Weinig <sam.weinig at gmail.com> wrote:
>
>> I am not sure I agree.  Does our behavior actually cause any real bugs in
>> the places you have tracked down?  The log spam really doesn't seem like an
>> issue, we can remove it if we want to, but have found it useful in the
>> past.
>
>
> Speaking as someone who working on a web app, the log spam is
> a significant issue because:
>
>    1. It clutters up the console output making it harder to find the real
>    error. (It is hard to explain how much worse this makes the experience
>    until you have to deal with a sophisticated web page. Image looking at the
>    logs from your app and seeing lots of error messages -- many of which are
>    this one and then a real one hidden among them -- from personal experience.)
>    2. When more sophisticated end users see it, they think there is a
>    problem in the app and report it (and it could be that they include this in
>    their error report and ignore other more important things).
>
> I understand that that the console/log spam is useful to detect real
> issues as well (given that WebKit doesn't throw an exception in this case).
>
> Would people find it acceptable to have window.webkitCanAccess so that a
> web page can use that property first to detect the cross origin issue and
> avoid doing an access which would trigger the console spam? (I would also
> be fine with an exception instead of log spam.)
>
> Thanks,
> dave
>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120322/f724d1f0/attachment.html>