 |
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
mwobensm - [08/19/08 04:32 PM ]
Confirmed. The error is cosmetic. Exposes no functional or security issues.
agreed, the error is in fact (mostly) cosmetic. But there's certainly got to be some reason the flash plugin is insisting on looking at the location of the parent/top window, as opposed to looking at it's own location ("self.location" for instance). I would hazard a guess that it's got something to do with the plugin's security context checking, possibly related to cross-domain communication and the crossdomain.xml? Or maybe it has to do with checking for LSO's ("flash cookies")? Or something along those lines.
The point should also be made that this behavior does *not* seem to occur in IE, because none of my JS error trapping/debugging tools pick up on it. Also, as noted by my several notes in the referenced mozilla bug thread, the presence of this error (plugin at fault), along with it's ambiguous error message (FF at fault), can (and did) lead to some errant troubleshooting because it misguides in what it's about. My issue specifically was that I had some code that was in fact doing an ExternalInterface call to "window.location.href.toString", and owing to the similar nature of this error message ("Location.toString"), I was certain that the two were related. It took 3 days of testing and debugging my code before I was able to confirm that my code had nothing to do with this error. And then, there was no documentation available from Adobe as to why this should be happening. So I spent another several days assuming that maybe it was a Mozilla bug of some sort. So, more than a week later, and no closer to a resolution, I finally arrived at the conclusion that the plugin itself was spuriously attempting some call to the parent/top window/frame's location property, and failing to robustly call that with a try/catch of some sort to handle the case when the parent/top window/frame is in a different domain. I guess my point is this: there's got to be some reason the plugin needs (or needed in the past) to make this call. And if it has any bearing on what happens when it cannot make this call (because of the cross-domain situation) then it might expose a logic problem more serious than just "cosmetic". But even if not, and it's just a totally spurious call... the fact that it's there and so cryptic is quite misleading to developers. apparently, this same issue also exists inside the new Google Chrome browser... which apparently reports the error much more generically and less specifically as something like:
"Unsafe JavaScript attempt to access frame with URL http://domain1.com/ from frame with URL http://domain2.com. Domains, protocols, and ports must match." Unable to replicate as of yet (need more details from users), but multiple reports of users having IFrame content blocked due to the error that is thrown. Seems to be triggering protective behavior from some pop-up blocking and security software. Possible revenue impact to online advertising firms.
Can anyone check into the possibility that it's the SWF trying to send forbidden requests or headers?
Ref: http://www.adobe.com/go/tn_14213 http://www.adobe.com/go/kb403185 And there are some unconditionally blocked headers: http://www.adobe.com/go/kb403030 It seems pretty clear that the error is indeed having the Flash plugin trying to access the top window's location property, and in cross-domain situations (ie, when flash is inside an iframe at a different location), this is a security error. I would doubt that flash was sending headers erroneously and yet the browsers were catching this and reporting it as unauthorized access of window.location.
It is true that headers could cause a similar problem, if flash were sending them automatically just because it loads. But as far as I can tell from my testing, it doesn't appear that the plugin is doing anything else automatically during its loading which causes security issues -- only trying to access a property in a frame outside its own. It's understandable that Flash would want to know what domain it's running in -- In fact, I *REALLY* wish Flash would detect this and expose it through actionscript -- it only exposes the domain/URL of where the SWF came from, not the URL of the page it's running in. Right now, I have to make a javascript call through external interface to accomplish that task. But, I think the point I've tried to make about this is that Flash should be trying to reference *only* the current frame's properties... so something like "self.location" instead of "window.top.location". That's the best way to avoid this type of problem. Or, alternatively, flash could wrap it's call in a try/catch so that at least if it fails, an uncaught exception doesn't get logged to the browser. In both Facebook Platform and Facebook Connect, we make heavy use of IFrames and Flash, and this error causes innumerable problems. Not sure why you say it is a "cosmetic" error since it seems to cause javascript to throw exceptions. We've found that the only solution is to turn off Flash in Firefox and tell clients to avoid using flash within iframes in their applications.
Is there any workaround for this problem? I haven't been unable to figure out a solution. This blog post describes the problem in depth and provides some examples.
http://blog.luckycal.com/?p=44 Please. work on it! This is not a cosmetic bug! this bug is quietly awful!
We have a lot of problems with flash banners from third parties. And we are losing revenues for it. its related with the new features about cross-site scripting as seen on this post: http://willperone.net/Code/as3error.php I will try to trace some data for you. I'd like to echo Sasha's comments from 6 months (!) ago, that this is really aggravating to deal with when developing for the Facebook Connect platform, which uses cross-domain requests for several important features.
Wow, can't beleive adobe can't find either a workaround or a fix for one bug for 6 months. I just recently started seeing it in my facebook app after we started using FBJS to adjust the iframe size.
Fellow sufferers, does anyone know of a workaround short of, uh, not using flash? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
In Progress
None
"Location.toString" uncaught (security) exception caused by improper Flash plugin behavior 