SWFObject tries to access top level iFrame resulting in cross-domain JS error

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Embed a SWF in a page using embedSWF()
2. Embed that page in an iFrame on another domain (e.g. a Facebook app)
3. Error is thrown...

What is the expected output? What do you see instead?

No error should be thrown, instead we see:

"Unsafe JavaScript attempt to access frame with URL 
http://apps.facebook.com/braintrainbingo/ from frame with URL: MY_FACEBOOK_PAGE 
 MY_IFRAMES_HOSTED_PAGE. Domains, protocols and ports must match."

What version of the product are you using? On what operating system?

Please provide any additional information below.

I'm not sure where in SWFObject the attempted access is happening, but this is 
quite likely to be the case for people making Flash games for Facebook where 
Facebook Canvas pages pull in the page inside an IFRAME (instead of an FBML 
Canvas page which is not as popular now).

Original issue reported on code.google.com by richard....@gmail.com on 8 Jul 2010 at 11:03

[GoogleCodeExporter]

Hi Richard.

So if you use just a standard <object>/<embed> insertion of your swf, then the 
error does not appear?

I am just trying to narrow the use case to a general Flash / externalINterface 
issue vs one specific to SWFObject.

I would have thought that we would have had more than one complaint if it 
wasn't working at all :)

Have you already read: 
http://www.adobe.com/devnet/facebook/articles/flash_on_facebook.html

Cheers,
Aran

Original comment by aran.rhee@gmail.com on 19 Jul 2010 at 5:59

[GoogleCodeExporter]

Hi Aran,

I haven't tried plain Object/Embed, but it does not prevent the application 
from working at all (indeed I make JS calls from within the Flash to it's 
IFRAME no problems, so it's strange).

You can see the error and view the source of the IFRAME/embed code here:

http://apps.facebook.com/braintrainbingo

Please let me know if you'd like me to test raw object/embed and I will, 
perhaps it's an AS library I'm using that is executing JS with something like 
window.top being referenced.

Original comment by richard....@gmail.com on 19 Jul 2010 at 6:04

[GoogleCodeExporter]

I will have a look at the app as soon as I can, but yeah, my hypothesis is that 
it is something in the swf rather than in SWFObject (but semi-happy to be 
proven wrong :)

In the mean time, yes, if you could try a standard object/embed, we can really 
quickly determine if SWFObject has any part in the issue.

Original comment by aran.rhee@gmail.com on 20 Jul 2010 at 10:14

[GoogleCodeExporter]

Richard, we have not received a response to Aran's request (it has been over 3 
months). I will close this ticket.

If you are still encountering the issue and feel the ticket still needs to be 
addressed, please post a reply.  Thanks

Original comment by platelu...@gmail.com on 8 Nov 2010 at 6:03

• Changed state: Invalid

[GoogleCodeExporter]

I too have encountered this error. Then i made a little test - 
- made an empty html page containing only a <script> tag with src pointing to 
swfobject.js (v2.2)
- put that page on domain A
- made another html page containing only an IFrame pointing to the first page
- put that page on domain B

running the second page in chrome generates that error.
i believe it's swfobject since that's the only element in either pages

Thanks
Hovav

Original comment by hov...@gmail.com on 18 Nov 2010 at 2:11

[GoogleCodeExporter]

Following hovavo's suggestion, I was able to confirm line 196 in 
testPlayerVersion() causes a cross-domain error in Firefox.

Permission denied for <http://domain-A> to call method Location.toString on 
<http://domain-B>.

The error is only thrown when setting the Flash mime type attribute on the 
newly generated <object> element: 

o.setAttribute("type", FLASH_MIME_TYPE);

If the value of FLASH_MIME_TYPE is changed, the error is no longer thrown.

Also, it appears that if lines 196 and 197 are swapped (adding 'type' attribute 
to the <object> AFTER appending <object> to page), the error goes away.

196  o.setAttribute("type", FLASH_MIME_TYPE);
197  var t = b.appendChild(o);

changes to 

196  var t = b.appendChild(o);
197  o.setAttribute("type", FLASH_MIME_TYPE);

Original comment by platelu...@gmail.com on 19 Nov 2010 at 12:24

• Changed state: Accepted

[GoogleCodeExporter]

I attempted the above fix above but it did not seem to work for me. I have also 
setup a sample iFrame application with a blank SWF to confirm. 
http://apps.facebook.com/swfobject_errortest/

Here is my modified SWFObject per comment above since it didn't seem like this 
change was checked in:
http://krisrange.com/test/swfobject_errortest/js/swfobject.js

Original comment by krisra...@gmail.com on 18 Jan 2011 at 10:10

[GoogleCodeExporter]

Fix suggested above only helps for empty page (without actual SWF embedding), 
but when you try to embed, error comes back.

Original comment by niz...@gmail.com on 20 Jan 2011 at 4:54

[GoogleCodeExporter]

Delving deeper into this issue I've come to the conclusion that it's not 
actually SWFObject related. The bug can be replicated by letting any 
crossdomain iframe try to add any kind of flash object tag into itself through 
javascript.

There is a related issue open on Chromium for example:
http://code.google.com/p/chromium/issues/detail?id=76748

And from what I can tell Firefox 4 has gotten rid of this message.

Original comment by duztdr...@gmail.com on 7 Apr 2011 at 12:37

[GoogleCodeExporter]

Testing locally in Chrome also shows the error.

Further testing reveals the error occurs twice: once as described above, with 
setAttribute on line 196 in the testPlayerVersion function, and again on line 
457 in the createSWF function; in the createSWF instance, it's the use of 
replaceChild that causes the error to appear. 

    el.parentNode.replaceChild(o, el);

This is a perfectly valid and legal piece of code that is not making any 
attempts at cross-domain JavaScript. 

For what it's worth, I tried replacing 

    el.parentNode.replaceChild(o, el);

with

    el.parentNode.insertBefore(o, el);
    el.parentNode.removeChild(el);

and it threw the same JS cross-domain error.

I am concluding that it's a browser bug; it doesn't prevent SWFObject from 
functioning, it only causes an error to appear in the console in *some* (not 
all) browsers. Trying to come up with a workaround that silences the error 
could possibly lead to new bugs, so this issue will be marked as "wont fix".

We're certainly happy to listen to suggestions if anyone has any ideas.

Original comment by platelu...@gmail.com on 22 May 2011 at 5:22

• Changed state: WontFix

[GoogleCodeExporter]

Submitted my findings to the Chromium issues list:

http://code.google.com/p/chromium/issues/detail?id=76748

For documentation purposes, I'll copy my message below:

-----------

I've investigated this issue on behalf of the SWFObject team, and found that 
DOM node manipulation sometimes leads to the error showing up in Chrome's 
console (tested in Chrome 11, Mac OS X 10.6.7).

Here's the SWFObject issue: 
http://code.google.com/p/swfobject/issues/detail?id=481

The error occurs twice when using SWFObject 2.2 in an iframe. The first time 
the error appears is when testPlayerVersion() is invoked.

    o.setAttribute("type", FLASH_MIME_TYPE);

"o" refers to an <object> that has been generated using document.createElement, 
and FLASH_MIME_TYPE has a value of "application/x-shockwave-flash". For this 
particular example, Chrome's cross-domain error can be silenced in two ways: 

1) change the order of the DOM manipulation; if setAttribute is invoked AFTER o 
has been appended to document.body, the error disappears.

    o.setAttribute("type", FLASH_MIME_TYPE);
    var t = b.appendChild(o);

changes to 

    var t = b.appendChild(o);
    o.setAttribute("type", FLASH_MIME_TYPE);

2) if the value of FLASH_MIME_TYPE is set to something other than 
"application/x-shockwave-flash", the error goes away.  Of course this is not 
very useful, but it's curious behavior.

The error occurs a second time when createSWF() is invoked. In this case, it's 
the use of replaceChild that causes the error to appear.

    el.parentNode.replaceChild(o, el);

"el" refers to a <div> in the iframe document, and "o" refers to the newly 
created <object>. This is a perfectly valid and legal piece of code that is not 
making any attempts at cross-domain JavaScript. It shouldn't be throwing an 
error.

For what it's worth, I tried replacing 

    el.parentNode.replaceChild(o, el);

with

    el.parentNode.insertBefore(o, el);
    el.parentNode.removeChild(el);

but the error still appeared. 

In both cases, Chrome is throwing an error when the iframe's DOM is being 
manipulated, but the parent frame is not being referenced at all in either 
case. There should not be a cross-domain error.

Original comment by platelu...@gmail.com on 22 May 2011 at 5:41

[GoogleCodeExporter]

I believe Ext JS 3.4.0 is also suffering from the same problem when cross 
domain iframed in Firefox 4.

http://www.sencha.com/forum/showthread.php?137437-Ext-JS-app-in-iframe-in-Firefo
x-4-gives-quot-Permission-denied...-quot-onDomLoad&p=615360

They have a function called testPlayerVersion in ext-all-debug.js:
    function testPlayerVersion() {
        var b = doc.getElementsByTagName("body")[0];
        var o = createElement(OBJECT);
        o.setAttribute("type", FLASH_MIME_TYPE);  //<------Incorrect sequence of this line
        var t = b.appendChild(o);                 //<------and this one
        if (t) {
            var counter = 0;
            (function(){
                if (typeof t.GetVariable != UNDEF) { //<------ Errors on this line
                    //...
                }
                //...
            })();
        }
        //...
    }

Original comment by c.wester...@gmail.com on 17 Jun 2011 at 10:54

[GoogleCodeExporter]

We use code based on SWFObject 2.2 in jQuery.jPlayer (and give you credit) and 
experience the same problem with iframes.

Firefox 5 and IE9 do not give any errors. Chrome seems to be the one that 
throws the error.

Error or not, the Flash works in the iframe.

Doing the equivalent of (1) above, actually increased the number of errors 
generated by Chrome for us:

   o.setAttribute("type", FLASH_MIME_TYPE);
    var t = b.appendChild(o);

changes to 

    var t = b.appendChild(o);
    o.setAttribute("type", FLASH_MIME_TYPE);

Original comment by mark.pan...@gmail.com on 6 Aug 2011 at 5:04

[GoogleCodeExporter]

Still seeing this error with SWFObject 2.3. The flash object on the whole 
appears to work as expected, but if you attempt to invoke a webcam, the accept 
and deny buttons do not respond to mouse input.

Original comment by p...@theorigin.net on 6 Aug 2012 at 11:18

[GoogleCodeExporter]

I am also seeing this error on an updated Chrome, though SWFobj ver is 2.2

Original comment by mishasof...@gmail.com on 23 Sep 2012 at 8:10

[GoogleCodeExporter]

"I'm using jquery webcam and when I try to add the "webcam object" I get Unsafe 
JavaScript attempt to access frame with URL (facebook url) from frame with URL 
(my app url). Domains, protocols and ports must match."

The object is inserted but the buttons to allow and the deny the access to the 
webcam, doesn't respond to the clicks of the mouse or if I press the TAB key 
till I select the allow button and then press SPACE also nothing happens

Original comment by fabioant...@gmail.com on 16 Oct 2012 at 6:09

[GoogleCodeExporter]

This continues to be an issue.

Original comment by gmail-in...@flyingcroc.net on 24 Apr 2013 at 7:24

[GoogleCodeExporter]

Has someone find a way to fix this? I mean catch the error or something?

Original comment by Sebastia...@gmail.com on 30 Jul 2013 at 9:33