I'm using Floatbox on a number of pages, and on just one page, when I click on the link to only the first floatbox, I get an error message that says "Stack overflow at Line: 0" - and only in IE7.

Any suggestions?

No suggestions without being able to see the problem in action. Got an online link I can look at?

Hello, I got the same problem. There you can see the problem.

http://sigeom.mrnf.gouv.qc.ca/signet/classes/I1107_accueil

- At first click on ?Courbe isovaleur (carte de contour) 1:50 000?, there you can see FB in action. Works fine.
- Then change the language to English (right top of the page)
- try back one link like ?Isovalue curve (contour map) 1: 50 000? and ist's not working. In IE7 I got the Stack overflow error.

I read this, I don't know if it could be relate...
http://stackoverflow.com/questions/226102/stack-overflow-in-line-0-on-internet-explorer

Thanks

I'm really glad to be able to see an instance of this problem that I can follow up. A couple of other folks have mentioned it, but not given me any meat to work with. I hope you don't mind trying some small experiments on our mutual behalf.

There's a huge amount of stuff going on on that page that could be the source of the problem. I suspect the problem lies with some of the other code on that page, or at least a conflict between that code and floatbox. But first, let's make sure it's not floatbox itself.

In the floatbox.js file, you need to set urlGraphics correctly because you have customized the install locations for the floatbox files. Set urlGraphics to '/signet/images/jquery/floatbox/'. If that does not remove the stack overflow problem, then the problem almost certainly resides elsewhere.

After turning the script debugger on in IE8, I see that the jquery library is throwing a script error on the line "var id=elem[expando]" (no such field exception), but only after switching languages through the link at the top right. So that is highly suspicious.

To narrow it down, I'd like to remove javascript code from your page until the problem goes away. The first thing would be to drop the inline javascript from the head section that begins "jQuery(window).bind(".
If the problem is still there, we should then remove "../script/lib/jquery.pngFix.pack.js".
And if that doesn't make the problem go away, we should remove the jquery library itself, "../script/lib/jquery-1.2.6.min.js".

(I understand you need this stuff, we're just trying to isolate the problem).

And finally, after we know a bit more about the problem from these experiments (and assuming correcting urlGraphics didn't resolve it), would you be willing to point your floatbox script and css include lines to the files on my test server so that I could look more closely at the script behaviour while generating the error from a test page on your site?

Hi, I did some testing and it is working when I removed those lines :

$("#I0000_entete").load("I0000_entete",{alias: &#039;<%INC ALIAS_CLASSE%>&#039;});
$("#I0000_piedPage").load("I0000_piedPage",{});

I use them to load my heading and footer pages. Those pages doesn't have any script in it.

Like it is working fine in FF3, I'm not able to see the error. I don't have IE8.
Maybe the error is cause by jQuery load function???

And yes I'm willing to point on your test server.

Great. If you can point your includes to http://randomous.com/floatbox324/floatbox.js and http://randomous.com/floatbox324/floatbox.css I'll do some slicing and dicing this evening (Pacific Time). (It's best not to use my test server at this point.)

It's done.

Thanks!

I've found the problem and it is in the floatbox code. The problem occurs when both the urlGraphics path is not correct and the image referred to in the href can't be found. When the loading of the requested image fails, floatbox's onerror response is to load the "404.jpg" out of the urlGraphics folder. If that jpg also can't be found, onerror is fired again and starts to loop until the stack overflows.

This only occurs in IE because IE changes the img.src path to the full URL, including the protocol and host parts, when handed a relative path. The other browsers just leave it relative. Floatbox has code to prevent the endless onerror looping, but that code doesn't handle IE's modification of the img.src value.

There is a fix. Around line 1212 in floatbox.js, find the lines:
loader.onerror = function() {
if (this.src !== that.notFoundImg) this.src = that.notFoundImg;
};
Replace that middle line with:
if (this.src.indexOf(that.notFoundImg) === -1) this.src = that.notFoundImg;

Floatbox versions after v3.24 do not have this problem.

My previous response addresses the general problem of floatbox generating a stack overflow in IE. In this response I want to address the problem specific to your page of the map image getting a "not found" response after switching the page language.

This appears to be an IE bug. After switching pages, the fetch of the image fails even though the url used for the fetch is identical. For other folk's information, I should mention that the url in question is an ftp:// link with access credentials embedded in the url (i.e., a little unusual). It appears that IE is screwing up somehow with a re-fetch of that same image url from a new page.

We can't fix that bug, but we can work around it. I would suggest bringing that image into your own site and serving it from there as a normal http get from the same server. Then it's pretty much guaranteed to work as expected. If there's a reason why you can't do that, try putting a question mark at the end of the url. (..../MA.PNG?). This should cause IE to bypass its own image cacheing and thereby avoid the bug. (or maybe not)

Thanks for hooking your page into my script source for a bit. I'm relieved to get to the bottom of these occasional stack-overflow rumours I've been hearing.

Cheers...

Thanks to you, it's working fine now.

I replace the line in the floatbox.js and put back the images on the web server. The question mark at the end of the url didn't worked. The only reason why we put those images on a ftp server was because they're gonna be updated alot, easy way for the organization to put them online quite fast. It's not a major problem.

Thanks again!