New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IE compatibility #16
Comments
I don't get it. What is happening in IE? What does it mean that "IE gets tripped"? You should elaborate, or even better, reproduce the issue in http://jsfiddle.net/ if possible. |
tripped meaning IE stops loading completely or/and does not trigger complete. I'll try to add an example though. |
Hi, I fixed it (I hope ;)) using new Image objects for the load handler. $images.each( function() {
// find out if this image has been already checked for status
var cachedEvent = $.data( this, 'imagesLoaded' );
// if it was, trigger the corresponding event and finish
if ( cachedEvent ) {
$(this).triggerHandler( cachedEvent );
return;
}
var img = new Image();
$(img).bind( 'load.imagesLoaded error.imagesLoaded', imgLoaded );
// cached images don't fire load sometimes, so we reset src.
var src = this.src;
// webkit hack from http://groups.google.com/group/jquery-dev/browse_thread/thread/eee6ab7b2da50e1f
// data uri bypasses webkit log warning (thx doug jones)
img.src = blank;
img.src = src;
}); |
reproducing was actually a real problem. Fix for me was so to not use the webkit specific hack which seemed to have caused wrong load things in IE IMHO. |
@grmlin your solution destroys the functionality of proper/broken images differentiation, as the events are triggered on a @cthedot even if this would work (which seems unlikely, but as I've mentioned, IE has been always weird...) we can't use that as jQuery.browser might be removed in future versions of jQuery. Also, it is a bad practice :) Nevertheless, I wanted to see what are you guys talking about, so I've had to create a more extensive testing examples. It even made me do the loremImages plugin :) So here are the pages I came up with: Dynamically inserted images test & Static images test Dynamic test is loading 100 random 300-400x400 pixels big images with 2% chance for loading broken ones, while static test is just set of 100 random images already included in HTML (just to be sure that dynamic insertion is not fixing the problem from whatever reason). When the pages were done, I've fired up some podcast so I'd have something to listen to while I was spending an hour refreshing page in IE7, IE8, and IE9. Aaaaaaaaand there was not one time the plugin would misbehave, or callback would not fire. Not once .... It is also good to note that I'm testing IE7 & IE8 in IETester (which is not 100% reliable, but it is as close as it gets without running virtual machines), but IE9 is native, and it still had no problem executing all callbacks. So what now? Sometimes it takes a long time for a browser to decide whether an image is broken or not (even ~10 seconds). Could it be that you were impatient and decided that it didn't fire while one of the images was still in loading state? Or are you using |
@darsain You're right of course, I forgot broken images as I don't have to deal with them in the project using you code. I'll look into your great test with an IE after the weekend. |
@darsain A more general comment (and BTW, thanks for your work, still great!): I know browser sniffing including jquery.browser is "bad" practice but IE is bad practice too ;) On a somehow unrelated but OTOH strangely related incident I run into a jquery plugin (any some of my own code) using Modernizr to "feature" check for css3 3d transforms. Firefox 10 which does support these now but still failed on both the jquery plugin and my own code as Firefox works slightly differently (e.g. perspective(100px) instead of webkits perspective(100)). Guess what I am trying to say is that even feature detection does go wrong sometimes. Guess this is not the place to discuss this issue here though ;) |
@darsain I tried the testpage in IE8 and 9 with a lot of pressing F5 for reloads in between loads or just hitting RETURN when on the URL bar or reloading by pasting the URL over and hit RETURN. Seems it does work, had 1 or 2 hickups though when apparently the browser seemed to have finished loading but the callback was not triggered. My specific problem was with a lot less images (4-5) which were much bigger though (~80-120kb each) in which the problem was much more frequenst. I guess this would be a major hassle but of course it would be nice to have a static testpage with only a few but larger images on. Also this would be easier to test with lots of reloads in between loading. Anyway, thanks for your work! |
Ok, I've added two more tests: Big images dynamic & Big images static Plus, all test pages now load experimental version of var BLANK = window.console ? 'data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///ywAAAAAAQABAAACAUwAOw==' : window.location.href+'#'; Reasoning: We are using data uri so the console would not be polluted with reports about missing/broken resources. If there is no console (IE6, IE7, and IE8 before you fire dev tools), use This should stop forcing IE7 & IE8 to render bunch of data-string images, which seems to be freezing, or doing something to your IE's. The problem with this is, that IE8 registers Anyway, try to test it (in IE8 without dev tools open), but I think I'm done here until there will be more information about what exactly is happening to you :) |
@darsain I admire your patience :) (really!) Just to understand the test now: The "big static" should load all pictures and do the callback (Deferred is resolved) each time, there should not be broken images when using the default page? Right? If so:
If I did not understand the test right I am sorry and please correct me. I check the latest code on the original page at work at the beginning of the week anyway again... Anyway, thanks a lot already! |
If the progress bar loads to the end, and ANY information about loaded/proper/broken images or deferred state is displayed, it means the plugin works correctly. The purpose of So again, if the progress loads to the end, and information about image stack is displayed (Total/Proper/Broken count & Deferred state), than everything works fine. |
in that case the testpages work for me, still need to try in realworld example but looks very good. Thanks a lot! |
@darsain After changing it to the following it does work though: var BLANK = (!$.browser.msie) ?
I try to install XP Mode with a "proper" IE8 but still have no high hopes for being able to provide better testpages. What do you think? |
Setting If you are testing it in IE9 with Document mode: IE8, than Modernizr check for data-uri is here. I haven't used it as IE8 does support data-uris, so it was pointless. That's why If Yes, we could test for a browser inside the plugin, but I'm really struggling with doing such a bad practice to fix a bug that I've yet to consider as confirmed. I mean, seriously guys... none of you provided any examples, or described the problem. I had to spent few days creating testing pages and deducing myself what could be the issue from your reports, and now it seems that you are not even testing in a proper IE environments. Right now - for me - it seems the problem is in IE8, and that it "freezes" or does "something" to the imagesLoaded execution when it has to render bunch of data-uri images that will get immediately replaced by normal urls. But I don't know if that is even semi-accurate anymore... I wish I could install VPC images myself and test it, but that won't be possible for some time. I'll try to figure something out. |
OK, I've changed So... I'm not gonna include any changes related to this issue into the |
First, thanks very much for your patience, considered effort, patience and informative answers! Today I installed XP Mode with (really) native IE8 on my work PC and tested the whole stuff again and from the begining. I have to admit and need to confirm that the plugin does work now. I might stand as a complete idiot and if you are majorly pissed off I'd understand that and am sorry for all the hassle. At least to me the "testing JS for IE8 in IE9 is unusable" was news even as I see myself as a somewhat experienced webdev... (And for proper development for IE8 almost a complete desaster esp when IE10 comes out. I guess hardly any developer will install XP Mode or any VM just to test for this stuff. Also if you still need to dev for IE7 or even 6 this is almost impossible to do. And it seems there are hardly any Windows webdevs out there any more anyway - another topic alltogether.) Anyway, thanks for the plugin and at least I have learned something (again). Sorry again but also much thanks! |
Hello. I believe I am having a similar problem, but it seems for only IE 9. My site uses your plugin here: http://216.224.183.126/category/work/ As far as I can tell, I cannot find one consistent pattern to when IE9 decides to allow imageLoad to work or not. I have been trying to debug it for the past few days as sometimes there will be a long string of successful loads, and then it will switch. Have tried it on different computers at work. It works on Firefox, Chrome, Safari, and IE8. |
@zhiwan duuude, that's one hell of a mess in code you got there! :) So lets fix you up. First of all, the problem is not in The problem is in Quick fix for you? Place/Load |
Hoooollyyyy Mooollyy. How did you go through my mess so quickly? Yah...this is my first foray into writing lots of jquery code and with an extremely finicky client under a short time constraint. I hope next time it will be cleaner. I tried placing the imagesLoaded plugin after isotope but that didn't seem to solve it. But replacing fn.imagesLoaded with fn.blah worked. Man...thanks so much! |
I don't mean to dig up a corpse thread but I was having problems with images not loading in IE7 (native version in VM). It would only happen randomly upon refresh and IE8/9 work fine. I was curious to try out the test pages that were posted but they're down. However, I just want to confirm that Darsain's suggestion works, i.e: var BLANK = window.console ? 'data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///ywAAAAAAQABAAACAUwAOw==' : window.location.href+'#'; Shouldn't this be included in the plugin? I know using the presence of a console object as basis isn't optimal, but isn't it better than to have it randomly break in IE7? |
@deepfriedmind I appreciate you chiming in. But we have to be realistic with the hours spent on maintaining this resource, IE7 is way old and we're no longer officially supporting it. |
hi,
first thanks for this great plugin.
It seems to work in IE sometimes, but not always (esp in IE8 but also 9). Seems IE gets tripped by the set to blank "hack" (it is a hack for webkit AFAIU, is it not?). I added an IE check (I know not good practice but the hack seems for webkit and maybe should stay for webkit only) and only if not do the "this.src = blank;" thing. Firefox does not seem to bother either way by the way...
I had the IE problem specifically with http://tympanus.net/codrops/2011/09/05/slicebox-3d-image-slider/ which includes the imagesloaded plugin but even after update to newest was most of the times failing (the demo seems to work but on a busier page it mostly did not).
If you want I can add the complete code.
Have you run into such an issue somewhere? I tested under Windows 7 64bit IE9 and 7/8 compat mode settings.
Thanks!
The text was updated successfully, but these errors were encountered: