Floatbox (5.7.2) does not work with older Firefox, at least Version 3.6.13

1. Do we care?

2. Everything on the demo page works fine for me using Firefox 3.0.1.

This strange issue does only occur when the options are set manually in another script other than options.js

It seems that with this special 3.6 Version of Firefox Floatbox does ignore already loaded options.

So on the Demo-page everything is fine, and for these special cases I can work around this.

Just to let you (and others) know if something similar happens there.

Correction: It isn't the options, there's something else interferring with floatbox in this particular browser-version.

I'll have to check this more deeply. If the real cause comes up, I'll get back to you.

Seems to be options-dependant, can't reproduce it on demo-page.

If that help you to narrow down the issue, ff-console throws the error
fb.cbk is not a function

If you care to link me in to the page that's failing in old Firefox I'd be glad to take a look and try to figure out why.

It's something whacky with the loading of floatbox on your server.

I replicated the test page on my test site. When I loaded floatbox.js and floatbox.css from your servers, it would not work in Firefox v3. When I then loaded the floatbox files from my own server, it worked fine.

You're doing unusual things with the loading of options.js. This may well be what is breaking old Firefox. The options.js file is minimized and appended to another js file which contains jquery and a bunch of jquery modules. This is an odd place to put the options. If you want to append options.js to something, append it to floatbox.js, for obvious reasons. If you do so, you can remove the "typeof fb" check because "fb" is guaranteed to already be established earlier in that same file. Also, you have a typo in that appended options assignment. The last semi-colon terminates the if block. It should be moved inside that block and terminate the fb.options= assignment instead. I wonder if this misplaced semi-colon could be breaking Firefox 3's javascript parser?

But please first discard this tricky business of appending options.js to other files. Load floatbox with a fresh clean unmodified download of the current zip file, check that that works fine using the standard lazy load of the supplied options.js file. If it's fine, drop your customized options.js file in place. If still fine, try appending that options.js file to floatbox.js. If something breaks along the way, all I can tell you is "don't do that". I suspect there won't be any trouble as I have my options.js appended to floatbox.js on this site, and old Floatbox works fine here.

In the last two hours I've been deep down the rabbit-hole as far as I could get - and you'll never get a clou what is interferring here...

First I want to thank you for going into this and leading me to the right direction. Your opinion about the options-stuff is welcome, but there is neither a problem with missing semicolons nor the placement of the options itself. I know that this is "uncommon", but for my extensive setup it's the most performant solution also respective automatic browser cache handling.

To keep the tension a little bit more:
- The problem still occurred with original fb-setup and -options.
- The problem still occurred after disabling all jquery and other main-scripts.

The problem is, for what exact reason I cannot tell, ADDTHIS 2.50 interferring with FLOATBOX.

It all came down to one single addthis-config-parameter:
var addthis_config={... ui_language:"de" ... };

After removing this language-pre-setting, all works fine.

If you are interested in further investigation, this is the js-code for AddThis V2.5:
http://s7.addthis.com/js/250/addthis_widget.js

Floatbox itself works, Addthis itself works, but both have a problem with eachother in Firefox3.

And why there is a difference between loading the fb-files from your or my server, would be interesting, too.

UPDATE:
as I just found out, there is the same problem with wibiya-toolbar.

Both seem to preload the google+ API, which seems to be the villlain here for floatbox in FF3:
https://apis.google.com/_/scs/apps-static/_/js/k=oz.gapi.de.scX5z8R7j4A.O/m=plusone/am=QQ/rt=j/d=1/rs=AItRSTO-ofjComacVSq0d1v_WP8hHopq1w/cb=gapi.loaded_0

Maybe worth a closer look, since this is another bug-dimension.

In Short: The real problem seems to be with Google Plus

There certainly is a misplaced (not missing) semi-colon at the end of your options assignment, but it's a harmless syntax error so not worth discussing further.

Really, it's a bad idea to append the options code to a javascript file other than floatbox.js. It's not the case that it's more performant nor more cache friendly to append it to file 'x' instead of file 'y', but that's not the reason I'm warning you against the practice. You are introducing fragility and setting up a structure where the options may not always get picked up.

One of the last things floatbox.js does when it is executing during load is set a brief (10 msec) timer to check for the presence of the options. This delay allows for any options appended to the currently executing floatbox.js file to be parsed before the timer fires. If no options are defined when that timer fires, a fetch of the options.js file that is in the same folder as floatbox.js is attempted. By appending the option code to another javascript file you are relying on that file being processed by the browser immediately upon conclusion of the execution of floatbox.js and are betting that the second js file will be finished processing when the previously set timer fires. Neither of these dependencies are guaranteed when appending the options to another js file, but both are guaranteed when the options are appended to the floatbox.js file.

In fact, just now I loaded your test page with Firebug monitoring the network fetches. The options.js file was fetched, indicating that indeed the delicate timing resulting from the options being appended to another file failed. In this case, with the options being fetched twice, I really don't know which set will get applied. It could be either depending on the timing of the scripts getting parsed and various onload events firing.

As for the problem of Floatbox not working on your site in Firefox 3...
The bug lies in Firefox 3, not in any of the scripts at play. Searching for similar problems reveals that FF3 had two bugs that are affecting us here: It will sometimes execute javascript in a different order than the script elements, and it will fire various onload events prematurely. It is highly likely that the out-of-order script execution and/or the onload events of script elements firing before they have completed is breaking the Floatbox startup. The Google+ API, AddThis, and the addthis_config changes are not the problem - they just happen to be the javascript that's on the page. Changing or removing these things changes the timing sequence of the javascript bits on the page. Some timing sequences succeed and some fail. Loading the floatbox files from my site rather than yours also changes the timings and explains why making that change got things working when the code that was being processed remained identical.

I've tweaked the script processing a little bit for the next Floatbox release that should make it more tolerant of out-of-sequence processing and onload events. It will be interesting to see if it behaves well on your site. (Remember, I can't replicate the behaviour on my test site.) I would like to close this off by repeating my very first response to your report. Do we care? I'm pretty sure the only people still running Firefox 3 are site testers like you and me. I think there are very few real site visitors still running that old version and at some point we have to say that it's just not time well spent trying to accommodate bugs in old technology that has all but disappeared.

Speaking of the next version, I've enhanced the fb.reload API function to make working with rotated images a breeze. Floatbox won't rotate images for you, but will make working with ones that you provide elegant and easy.

The timing-explanation makes sense to me, thank you very much.

This problem with FF3.6 was indeed mentioned by an elderly user (and has not happened on a test case) telling me "that something doesn't work". Always a good point to tell users to update their browsers, but made me also curious about the reasons (since floatbox itself officially works with firefox3.0+).

Thanks for the changes in upcoming version!