Bugs in Firefox 3.6

[desandro]

Bugs in Firefox 3.6

[darsain]

It seems that Firefox 3.6 in determining whether an image is loaded or not choose a revolutionary method called Random.

I've tried to find an additional condition for broken images check, like || naturalWidth === 0, but nope, Firefox is holding its dominatrix status and preaching the Random dogma.

And when I thought it can't be worse, Firefox made sure that I know who is the bitch here by nonchalantly triggering the loaded/error event on images waaaaaay before they have finished with loading.

After a few minutes with sore ass I've realized that I have no idea how to fix this shit... other than declaring this 7 versions old browser with manners from medieval ages as unsupported :)

This is even worse than old IE versions... and I don't feel like spending another whole evening digging into this issue because of FF 3.6 :(

[andreyvolokitin]

Thanks for answering!

So because in my project I`m actually do not need broken images detection functionality my solution was just to sniff for Firefox 3 and give it an old version of a script from here https://gist.github.com/268257 . While there are still some minor bugs in ff3.6*, the images loaded detection works more or less as expected.

*i.e. it seems like in a set of images with "imagesLoaded" handler on each FF3.6 waiting till ALL this images are loaded before executing their handlers, but not waiting separately for each image and then executing its "loaded" handler right away.

[darsain]

I've dug a little bit into that, and it seems that the issue with premature callback firing is the resetting of src on all images. When we do that, FF 3.6 might trigger load/error event on an image 2 times. First time almost immediately after the reset, and second time when the image is really done with loading... and I don't see any way how to differentiate between them.

So basically, the thing that makes this plugin work everywhere is the same thing that makes it not work in FF 3.6.

Nevertheless, I discourage you from using that old gist, as it has a lot of issues.

...

Ok, another evening spent on this plugin :)

I've played with it for a while, and came up with this version: http://lab.darsa.in/imagesloaded/jquery.imagesloaded.js

Please test the shit out of it and report back.

Change made: Before resetting the src, if ( this.readyState || this.complete ) condition has to be true. As far as I've tested it works, and it is faster! But ... this.readyState is basically an IE check :/ ... which right now has no drawbacks, because even the IE9 is not setting complete to true on broken images that has finished with loading (the main issue why we were resetting all srcs). No drawbacks except the fact that it is a bad practice, and IE might get it right someday, which will render this plugin less efficient than it could be in that particular future version (if they won't drop the readyState property). But at the same time, it makes the plugin faster in every other browser, and compatible with old ones as well.

Damn, that's one attractive bad practice...

[andreyvolokitin]

Okay, I`ve tested it on my project, and it works fine in Opera 11, FF3.6 (works like old gist) and 10, Chrome latest, IE7-9, and Safari latest.
The bad news: now plugin is broken in Opera 10.63.

[darsain]

What is happening in Opera 10.63? I've just installed portable version, and it works fine for me.

Also, in Firefox 3.6 "works like old gist" means that it triggers callback properly, but doesn't differentiate between broken/proper images?

[andreyvolokitin]

In Opera 10.63 it does not work with a set of images (did not check with single image) - I have an "imagesLoaded" callback on a set of images in my project, but this callback is never triggered.

In Firefox 3.6 it works as I described earlier, and this is like old gist from here https://gist.github.com/268257 works too:

I have a gallery with multiple images. Each image have an assotiated larger image copy, that needs for "zooming image" functionality. There is an "imagesLoaded" callback on each of these larger images, that should be triggered, when this individual image is loaded (the images are hidden with display: none). In every browser, except of FF3.6, script waits till each image is loaded individually, and when it does - triggers a callback for this single image right away. In FF3.6 it seems like browser waiting till ALL this images are loaded before executing any of assotiated callbacks for any image, and till then - it just hangs (images are pretty large in size and dimensions). So it sort of works.

I have actually only checked "image loaded" detection functionality, but not broken/proper images detection, because I have no test case\page for it (and actually do not quite understand how it should work (: ), and in my project I don`t use it.

[darsain]

That is really weird, because I have a test cases with 100 medium/big images and it works exactly as expected. Can you replicate the issue and put it online somewhere?

[darsain]

I take that back, there is an issue with proper/broken image differentiation in Opera 10.63, but at least the callback is being fired properly (after all images has finished loading).

[andreyvolokitin]

An imagesLoaded callback does not fire in Opera 10.63, when an image placed within a container with display: none, or image itself is hidden with display: none, here is fiddle: http://jsfiddle.net/ZqYvW/6/

[darsain]

Well, that's a different issue altogether. I don't know what is the correct browser behavior regarding loading of hidden images, but I know that forcing them to start loading is not the point of this plugin. The point is to notify you that they've finished with loading, which in your example works, and you can check it here: http://jsfiddle.net/ZqYvW/9/

The plugin does fire when image has finished with loading, but in Opera 10.63 that starts only after it has been displayed.

So I cannot accept this as an imagesLoaded bug :) sorry.

The only remaining issue I see is what am I going to do about Opera 10.63 firing load instead of error event on broken images. And by looking at its market share... well, it is definitely not a priority :) But it still bugs me...

[andreyvolokitin]

As far as I know correct browser behavior regarding loading of hidden images is to just load image, even if its hidden, even in Opera. And actually current version of the script works fine in Opera 10.63, and fires callback properly on hidden images.

But yeah, talking about market share, its not so important.

[andreyvolokitin]

And there is sort of workaround: in Opera 10.63 its possible to show image and immediatly hide it, in this case script will work: http://jsfiddle.net/ZqYvW/13/

[darsain]

Current version is doing hard reset of src on all images, and that probably wakes up the Opera 10.63 to load the image. However, that's what was causing the problems in FF 3.6, so the version on lab.darsa.in resets only the src of already loaded images (cached).

The workaround is nice, but irrelevant to the plugin :) As I've mentioned, forcing hidden images to load is out of scope.

Btw, simpler version would be:

$('.hidden-image').show().hide();

Or perhaps a global terminator style version :)

$('*').toggle().toggle();

But I imagine this would be pretty intensive on complex pages :)

[andreyvolokitin]

Hmm, I`ve checked this fiddle without imagesLoaded script in Opera Dragonfly and yeah - seems like Opera 10.63 does not load hidden image on initial page load. What confuses me, is that at the same time Opera 10.63 passes successfully this test here: http://www.quirksmode.org/css/displayimg.html

I saw this test earlier in Opera 10.63 and so was sure that it loads hidden images. Turns out that things are more complicated.

[darsain]

I've just spent a few hours trying to fix the issues in Opera. With mad binding magic I've succeeded, but as a side effect it introduced annoying flickering of loaded images in all browsers on each plugin call.

So, out of curiosity, I've checked the exact market share of Opera <11, and the biggest estimate I've found was 0.14% for all versions lower than 11 combined, and that is from December 2011.

I think I'll just double check & push the Firefox 3.6 fix, and respectfully ignore Opera <11 ...

[andreyvolokitin]

In my country market share for Opera <11 is also low (1.4%), and I could always use some workaround if needed.
Thanks for diggin in, great work!