Problem running slide show on IE9 browser

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.