Problem running slide show on IE9 browser

1) Script Title:
Unltimate Fade in slide show v 2.4
2) Script URL (on DD):
http://www.dynamicdrive.com/dynamici...nslideshow.htm
3) Describe problem:

I really like this slide show and have used it extensively building a new site. I admit I'm a newby to html and js, but I feel I've got all the basics right.

So the slide show works great online with Firefox, IE8, opera and chrome. But when I browse with IE9 the slides just don't run. Is there a fix please? I don't want to have to start over again... Thanks for any help.

The demo page for this script on Dynamic Drive works fine here in IE 9. Does it in your IE 9? If so, the problem is with your implementation and we would need a link to your page. If not, its some setting(s) in your IE 9 and/or other program(s) on your computer.

If the Dynamic Drive demo page works for you in IE 9 and you want more help:

Please post a link to a page on your site that contains the problematic code so we can check it out.

Here's the website

www.snowonsnow.com

the index page includes the slide show. I've found that hitting refresh / F5 in IE9 gets it to run, fine, but it doesn't run from initial load. Also every other page that includes the slide show has to be refreshed first to work. Thanks very much for your help.

Hi John. I've just tried the demo page for the fade show with IE9 runnig on our other PC (which is on Vista, if that is relevant at all?). And the same issue occurs - The demo also needs a refresh to run the show. So is the issue with our own set up of IE9 on our PC perhaps?

Does the slide show on snowonsnow run first time for you with IE9?

Thanks again, Chris

On the snowonsnow.com site Home, Stay, and Ski are all fine in IE 9 here under Windows 7. No refresh is needed. I cannot speak to Vista - I skipped from XP to 7, I never trusted Vista, so have nothing around to test IE 9 Vista. I do know that IE 9 was made for 7 and that because 7 and Vista share a lot in common, IE 9 can run on Vista, but that the preferred platform for IE 9 is Windows 7. That may or may not be an issue here. It might be - say an anti-virus program, or something else like settings, etc. as previously mentioned. I'm pretty sure though if it were simply IE 9 under Vista, and the issue showed up on the official demo page, we would have heard more about it by now, but perhaps not.

IE 9 also has 32 and 64 bit versions. The 32 bit version is the more reliable, and even though I have and can run both under Windows 7 on this machine, I use the 32 bit version. But I just checked the 64 bit version and at least under Windows 7, the snowonsnow site is fine in it too.

You can tell which bit version of IE 9 you're running by checking its Help > About. If it's 64 bit, it will say so on the version line. The 32 bit version doesn't say anything about which bit version it is.

Three things you can try:

1. Update jQuery. Change this:
   
   
   Code:

   ---

   <!-- IMAGE SLIDESHOW CODE  -->

        <script type="text/javascript" src="scripts/jquery.min.js"></script>
<!--        <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>        -->

   ---

   to:
   
   
   Code:

   ---

   <!-- IMAGE SLIDESHOW CODE  -->

<!--        <script type="text/javascript" src="scripts/jquery.min.js"></script> -->
        <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.5.2/jquery.min.js"></script>

   ---

2. Disable your anti-virus/anti-malware program(s) temporarily and see if that fixes it.
   
   
3. Reset all settings in IE 9:
   
   Tools > Internet Options > Advanced > Reset... > Reset

For best results close IE 9 completely after any of these changes to make sure they've taken effect. First thing after you reopen the browser, before you load the page to test it, empty the browser cache.

Be advised - You can easily restore your anti-virus, etc. after this test. But once IE 9 is reset, any customizations you may have made to it will probably be lost. If they don't survive the reset, you will have to make them again.

Sorry I cannot be of more help than that. I have a Skype friend who may still have a Vista machine hanging around, but it probably uses IE 8. Next time I'm on with her, if this is still an issue I'll ask her to check it out.

John, that's great, you've been really helpful. Thanks, Chris

Thanks. Did any of that fix it? If so, what was it?

And another thing occurred to me. We could force IE 8 mode. To do so place this meta tag:

Code:

---

<meta http-equiv="X-UA-Compatible" content="IE=8" >

---

as the first thing after the title.

That would be a last resort though because it stops you from using all of IE 9's advanced features for that page. But your:

Code:

---

<!--[if lt IE 9]>
<script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->

---

should make up for that.

Hi John. Sorry not to have come back to you earlier.

Great minds - I'd already tried the <meta http-equiv="X-UA-Compatible" content="IE=8" > code. And it worked fine. And the HMTL 5 elements (<footer> <header> etc) did work fine as well due to the "if lt IE9" code as you pointed out (see footnote). But on reflection I thought it wasn't a great solution. I'd have gone for it though if there was some general problem browsing the site on IE9, but you'd found no problem with it, so I'm concluding it's possibly a problem limited to IE9 running on Vista, or maybe even more likely a problem specifically with the combination of settings and virus software (we run McAfee) on this specific machine. And in the last case then, the problem is our PC, not the website.

I have tried updating the JQuery but it didn't solve the particular problem. By the way, would you in general advise the JQuery script part of the site to be frequently updated? I note that version 1.6 of JQ warns that some existing sites might need rewriting, so I suppose updating is not always a good thing? And, by the way number 2, I can see the JQuery stuff is obviously very useful and popular, but I've actually no real idea what it does / what is its exact function - would you like to enlighten me in summary? Tell me to go find out for myself if you prefer!

On your other suggestions (items 2 and 3 in your previous post) I've not actually tried them, again thinking that it's seeming likely a limited probem with this PC and/or IE9 on Vista, rather than a problem with the site. It's something I might get round to, but frankly I think I may just roll back this Vista machine to IE8. I also have a newer laptop running Windows 7, but ironically currently on IE8, so I'd bring that one up to IE9 so I can test still on both versions.

As you'll have realised from the start, I'm very much a beginner on all this so happy to take any further suggestions or comments you might have.

Regards, Chris

Footnote. Just for your interest, maybe, I got the "HTML5 with lt IE9" code from the O'Reilly/Missing Manual: Creating your own website book. In fact everything I know about this entire subject has come from that book or from the extra resources it suggests, like dynamic drive! To take a total novice starter to own functioning website, I rate the book as fantastic.

It should be tested, but yes updating jQuery periodically is good to keep apace with improvements. I haven't seen any problems from 1.3 on, with the exception that I usually wait until a version reaches its final 1.x.x before feeling really good about it. 1.4.2 had some problems, the 1.4 series ended at 1.4.4, which is very good. That's why I suggested 1.5.2 - the final version of the 1.5 series. 1.6.2 seems very stable though, so I'm going with it more and more, you might try it, as a lot of what's being added these days is for newer browsers like Firefox 5 and IE 9.

As to what jQuery is and does, it's a vast topic. Generally speaking it's a script library. That means it's a set of routines used to accomplish common and some not so common tasks. It's written in such a way as to allow the script author to use much less code to accomplish many things. It does so by providing a sort of shorthand for things, and a way to chain commands and events, and by taking into account variations among browsers to compensate for the differences so the script author doesn't need to, or at least doesn't need to as much. Another thing it provides are some additional programmatical methods, things that other computer languages have that javascript lacks. This saves time for the script author as well if s/he needs one or more of these, rather than have to write a complex routine to provide it.

There are details (including links to code and documentation) at:

http://jquery.com/

Hi John. Here's a further instalment. I've now tested on a different machine, this one running Windows 7, and with a completely fresh instal of IE9, and I still get the same problem - the site displays, except that the slide show doesn't run on first load, but then a refresh and the slide show does run. A refresh is needed on each separate page which contains the slide show. As an alternative to refreshing, two clicks on the compatibility view seem to do the trick. (The first click fixes the slide show but messes up the HTML5 elements, the second click puts the HTML5 elements right again). It is the same when loading the demo for the slide show on the dynamic drive website, i.e. a refresh is need to run the show

So I still have a perplexing problem here. I'm minded to put in the "force IE8 mode" meta tag you suggested a while ago - but it does seem to be a shame to have to go that way.

Any thoughts?

Thanks again, Chris

This thread seems to me to be around the same issues?

http://www.sevenforums.com/browsers-...avascript.html

I can't seem to duplicate the problem. Here's what I did - I cleared the browser's cache, then pasted the address into the addressbar and hit enter. Slideshow runs right off.

Is there some other order of events that might allow me to see the problem?

I start to doubt my own eyes. This is what i've just done (IE9):
- Internet Options - delete browsing history
- closed IE9
- reopened IE9
- typed in www.snowonsnow.com
- hit return

result = no change - slide show does not run without a refresh

frustrating!

Deleting the history doesn't necessarily do much. When you click on that there should be another screen for which items to delete. One of those is Temporary Internet Files - that should be checked.

But, if you had this problem from the start on a machine that had never been to the site before, the cache is probably not the problem, though it's worth double checking.

I'd go back to post #5 in this thread and try items 2 and 3 mentioned in it.

I'm thinking it might be an anti-virus or anti-malware program or even another add on like a search engine toolbar. If the two computers have this in common and disabling it fixes it, that would explain it. Or it might be settings in the OS.

But I can assure you there's no problem here, and that the script's author tested it in IE 9 as well.

Something else I just thought of. Do you know how to use the IE 9 developer tools to check for script errors?

With only a blank page in the browser, hit the F12 key, select the script tab in the utility that pops up. Load the page into the blank browser tab. After it loads, check the left hand side of the developer tools utility. Are there any errors listed?

Hi John. Yes, Temporary Internet Files was checked.

This is what came up on checking for script errors:

SCRIPT70: Permission denied
jquery.min.js, line 21 character 67
SCRIPT5009: 'jQuery' is undefined
fadeslideshow.js, line 18 character 1
SCRIPT5007: Unable to get value of the property 'getCookie': object is null or undefined
fadeslideshow.js, line 25 character 2

Chris

Try out these two pages:

http://home.comcast.net/~jscheuer1/side/cookie_test.htm

and:

http://home.comcast.net/~jscheuer1/side/nua_test.htm

The first one should alert:

Quote:

---

string

---

The second should give something like (it may be longer or shorter):

Quote:

---

Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; Zune 4.0; InfoPath.3; MS-RTC LM 8; .NET4.0C; .NET4.0E)

---

Neither one should give an error. But I suspect one or both may.



Note: I typed the below before I came up with these tests. It's still valid. But the tests may tell us more.

Those errors tend to support my third party program theory. The first one is:

Code:

---

P=navigator.userAgent

---

That's asking the browser what browser it is. And the error is "Permission Denied". The only reason to deny permission for such a simple request would be security, albeit a bit overzealous - to prevent a virus or other malware from identifying a potential target browser. However such a request is commonplace in a very large number of scripts, so it's unreasonable to deny it. If an anti-virus/malware program relies upon that, it's unsophisticated.

The next error is a result of the first, jQuery is not defined because of the first error.

The third error could be another 'security' type error, or just the result of the script already having been compromised. Probably the latter.

What's strange is the behavior on refresh fixing it. If some security program blocked it the first time, why not do so every time?

This leads me to believe it may be an add on like a search toolbar, but it still could be anti-virus/malware.

Hi John. The first test works, giving the alert "string" as you say.

The second gives the following error

SCRIPT70: Permission denied
nua_test.htm, line 7 character 1

What does that tell you?

Regards, Chris

Along with some supplemental searching the web I've done on the topic because of this issue and that result, it tells me that it's a setting in IE 9. It's unclear which setting or how to change it without editing the registry. It's also unclear if it's caused by another program like I was thinking before, or if it's all IE 9's own doing.

None of that really matters if you think about it because it's obviously too prevalent to address in any other way than to create a workaround for the IE 9 bug*.

First try this test page:

http://home.comcast.net/~jscheuer1/s...a_test_fix.htm

It should alert either that long userAgent response from my last post or something like that, or more likely:

Quote:

---

bug caught with no error

---

But there should be no error. If that works, replace your copy of jQuery with this one:

Attachment 4054

For ease of use you may rename it to:

jquery.min.js

upload it to the scripts folder on server. To make sure the pages are using it, clear the cache and refresh.



*See:

http://forum.jquery.com/topic/strange-behaviour-in-ie9

for information on editing the Windows Registry to fix this bug in IE 9. Always be careful when editing the registry, make a backup copy first.

I say it's a bug in IE 9 - I don't know for sure, because there are many posts around the web complaining about this, and not just as regards jQuery. My little test page also demonstrates this, as all it has on it is:

Code:

---

<!DOCTYPE html>
<html>
<head>
<title>Navigator User Agent Test</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<script type="text/javascript">
alert(navigator.userAgent);
</script>
</head>
<body>

</body>
</html>

---

And according to you, that was enough to set off this 'bug' in IE 9.

Once again, thanks John.

The test page works fine for me without error on IE9. I've tried it a couple of times - the first time it alerted the long userAgent response, the second time I got the "bug caught with no error" response.

I agree with you re the bug needing a work around solution. Reading the jquery forum discussion I noted one comment that the problem depended on "localization". What would you understand by "localization" in this context? I've been in touch with a friend in the UK (I'm currently in France) and, same as for you, he did not get the problem either. Is it at all feasible that the problem could depend on geographic location? I'll be back in the UK in a couple of weeks so could test it out then.

Anyway, back to your fix - I've tried it and it works. If you want to take a look I've currently set it up as a separate page on the site www.snowonsnow.com/indexjqfix.html

I see that your fixed jquery script is version 1.5.2. You recommended using this in an earlier post, but it didn't seem to solve the problem back then. I'm guessing then that you've made some special modification to the "standard" 1.5.2 version? Can you let me know what modifications you've made?

I'm still left wondering how many people round the world will have the same problem I've had - particularly as it doesn't actually occur for you or for the one other person I've asked (admittedly not a large sample size.) But as you point out, it must be pretty prevalent given the other posts around the web complaining about it. Thoughts?

Regards, Chris

For the purposes of this exercise we determined that the problem was a call to the browser's native navigator Object's userAgent property. That only occurs once in jQuery. I updated to version 1.5.2 for this only because it's a better version overall than is 1.4.2.

What I changed was (around line #66 in the uncompressed version):

Code:

---

        // Keep a UserAgent string for use with jQuery.browser
        userAgent = navigator.userAgent,

---

to:

Code:

---

        // Keep a UserAgent string for use with jQuery.browser
        userAgent = (function(){try{return navigator.userAgent;} catch(e){return 'MSIE 9.0';}}()),

---

This allows the browser to trap the error and continue, reporting itself as MSIE 9.0 - presumably the only browser with this issue. Otherwise (all other browsers and IE 9 when it's working properly) it gives the actual userAgent string. Either way all is as it should be and no error for IE 9.

It's still a bit of a hack though. It could have unintended consequences. I'll be happier when Microsoft fixes this. At least with the slideshow, since it doesn't use that part of jQuery, and jQuery itself doesn't require it for anything other than reporting the browser type and version if asked, it's fairly innocuous. I think jQuery would like to remove that (the $.browser Object) from its code anyway, as they're already discouraging its use in favor of the newer methods of feature detection it's implementing.

But we're not done. Since that worked in the uncompressed version, may as well make the change to the minified version and use that (saves time for first time visitors and for those whose cache has been cleared since their last visit):

Attachment 4060

One of the other things I learned about this bug while Googling on it is that apparently Microsoft is unaware of it. If true this is unfortunate because it bodes poorly for it being corrected any time soon. As for the 'localizations' aspect of this - I think that was just a generic term for computers. As in "Works OK on some computers, not on others."

The real issue according to that thread is that sometimes the registry entry for (highlighted part of the path is only for some machines, presumably those with 64 bit OS's):

Code:

---

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_OBJECT_CACHING\\iexplore.exe

---

gets set to 0. According to that thread it should be either blank or 1.