Unsafe JavaScript attempt to access frame with URL #352

Closed
gsuess opened this Issue Nov 11, 2012 · 7 comments

3 participants

@gsuess

Google Chrome (Version 22.0.1229.94) produces this error when testing cross-domain iframe (QUnit v1.10.0)

Unsafe JavaScript attempt to access frame with URL http://www.iana.org/domains/example/ from frame with URL file:///home/user/qunitbug.html. Domains, protocols and ports must match. qunit-1.10.0.js:1207

extractStacktrace qunit-1.10.0.js:1207 
sourceFromStacktrace qunit-1.10.0.js:1241
QUnit.test qunit-1.10.0.js:343
(anonymous function) qunitbug.html:20
p.event.dispatch jquery-1.8.2.min.js:2
g.handle.h jquery-1.8.2.min.js:2

How to reproduce:

Create a file with the following html code below and open it in a web-browser:

<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Demo for qunit test cross-domain iframe bug in Chrome</title>
<script src="http://code.jquery.com/jquery-1.8.2.min.js"></script>
<script src="http://code.jquery.com/qunit/qunit-1.10.0.js"></script>
</head>
<body>

    <div id="qunit"></div>
    <div id="qunit-fixture"></div>

    <script>
        $(function(){
            $("<iframe>", {
                src: "http://example.com"
            }).appendTo("body").load(function(){
                var iframe = this;
                test("foo", function(){
                    ok(true);
                });
            });
        });
    </script>
</body>
</html>

This does not happen in Mozilla Firefox! On Firefox it passes without issues even when run on an http server on localhost.

@Krinkle
jQuery Foundation member

Live reproduction: http://jsfiddle.net/SvJ5b/

@jzaefferer
jQuery Foundation member

Not sure what exactly is going on, but it looks like a bug in Chrome.

@jzaefferer
jQuery Foundation member

I still don't understand how that happens: Calling test() causes QUnit to extract a stacktrace, so that it can later display which test has failed. For some reason Chrome thinks that stack is looking at the iframe, not at the parent frame, where its actually running.

Would have to reduce this to just the iframe and the stack access to see if its really a QUnit problem or can be reported against Chrome.

@gsuess

I still don't understand how that happens: Calling test() causes QUnit to extract a stacktrace, so that it can later display which test has failed. For some reason Chrome thinks that stack is looking at the iframe, not at the parent frame, where its actually running.

Doesn't it somehow enter the iframes properties, because they (unlike on firefox) also get enumrated on the parent frame.

So it enters iframe.contentWindow and then tries to access all fields in there?

@jzaefferer
jQuery Foundation member

What enumeration and access are you referring to?

@gsuess

I don't know. What I mean is that somewhere a request is made for a list of properties of iframe.contentWindow. Firefox returns only the list of the accessible ones, where as chromes returns all of them, prompting some variable reporting loop to try to access them.

@jzaefferer
jQuery Foundation member

I just ran the jsfiddle from @Krinkle in Chrome 27 and it works just fine. Looks like the bug was fixed in Chrome itself. I'll close - if I missed something, we can reopen.

@jzaefferer jzaefferer closed this Jun 19, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment