Framebox Script

Page: 1

Author Post
I have an application that is integrated into many different web sites via frames or iframes. I had the floatbox.js script implemented and tested in stand-alone mode, but when I tried to switch to framebox.js and test it, it died with permission errors.

I don't have control over these external framing pages, so I couldn't add anything to the top-level pages - so framebox.js had to be fixed, 'cause I really like Floatbox!

It seems that there are still some references in framebox.js that call 'top.location.replace'. When I changed these to 'self.location.replace', it works like a charm in the framesets!
Registered: Aug 2008
Posts: 3382
Thanks for letting me know of the problem. Here's way more information about those lines than you probably want.

There are 3 lines that reference top.location.replace. The purpose of these lines is to be a frame buster buster. Some pages do a javascript check to see if they are running inside a frame and use top.location.replace to "bust" out of the frame. This jumps them out of the floatbox, which we don't want. (It's a battle of wills.) A good example of this is any New York Times article on the site. Frame busting code usually looks something like this:
if (top != self) top.location.replace(self.location.href);

What the frame buster buster code attempts to do is neuter the top.location.replace method so that it does nothing and the page remains within the floatbox box. It's not a slam-dunk cure. Only IE and Opera let you do this. Gecko and Webkit ignore the effort and keep the original replace() function intact.

I think what you are running into is access denied due to a cross-domain scripting attempt. It never occurred to me when putting that code in that someone would inlcude floatbox on a child iframe page that was being served from a different domain than its parent page. Oops - access denied.

So, yes, the code should be top.location.replace. Changing it to self.location.replace fixes the cross-domain scripting problem (because you're not accessing the top window anymore) but now the code does nothing. Which is ok, because the code never did much in the first place.

That code should either be removed, or wrapped in try/catch error handling. I'm leaning towards removing it because it is not effective in all browsers, but I'm open to other points of view if anyone thinks it's worth keeping.

You can safely remove the offenders by deleting all 3 lines that reference "top.location.replace".

Page: 1