images freeze in Ultimate Fade-in Slideshow

1) Script Title: Ultimate Fade-in slideshow

2) Script URL (on DD): http://www.dynamicdrive.com/dynamici...nslideshow.htm

3) Describe problem: Hi, thanks for ur great site, archive and work -

My prob with the UFiS is that when using multiple sideshows (6) on 1 page after linkd 2 another page and then redirected by the backbutton some images freeze - this is random. i tried to solve this by refresh onload and no-cache scripts in JS and ASP but non seem to solve the freezing problem.

Pls Ur help wanted here ...

I'd like to see this problem in action. What's the address of the page? What do I have to do to duplicate the problem? What browser does this happen in?

Without all of that information, I can only speculate, but here goes:

Sounds like you are taking the script to its limits. That coupled with the fact that some browsers, upon hitting the back button, just won't completely reload scripts on a page . . .

The only things I can think to suggest would be to try another script, and/or use less shows or images or use no script.

And, let me get this right, you navigate away from the page to another page, and hit 'back', that causes the problem, right? That being the case, how you get to the other page might be an issue.

The one script that comes to mind that might be a little different in how it behaves in the browsers, but that can be configured to look like U-Fade is Swiss Army:

http://www.dynamicdrive.com/dynamici...army/index.htm

Hi John,

yeah mayB Im driving the script to its max but i realy like it.

The address of the page is http://www.arttriq.nl/nieuw

The browsers i tested the page in : safari ie opera netscape firefox and flock, all on MacX. They all have some minor things but in safari and ie this problem occours.

At first instance I tried swissarmy.script but I dont need the navigation and Im not such a configuration expert thats why i used your UFiS.script.

Thanks 4 ur answer and mayB u can help me further...many thanks

Hmm, I have no Mac to test on. I have Safari 3 for Win and it doesn't seem to have the problem. They now have Safari 3 for Mac too, is that what you are using, or is it an earlier version? Or does this not happen all the time? As for IE on a Mac, almost nothing works in that.

If you are using an earlier Safari, and it is only in Safari and IE Mac that you have the problem, I wouldn't even worry about it.

With FF though, due to its inability to carry out multiple fades gracefully (a known issue with that browser and any script that does multiple fading and/or moving), you might be better off with Flash. Flash may or may not help with this other issue.

yup I dont use the last versions of the browsers unfortunatly - one cant allways get what he wants ... its ok with me that the freezing happens on some vieuwers. Thanks 4 ur helppp

Since I searched for a script or code that refreshes the page and empties the cache on reload or back-navigation and I couldn't find a working one can u help me with that? It can't rest my mouse till I find out how this can b done. I prefer a sollution in xmtl, css or javascript. To my iD this might also solve the problem in my case since all images r random.

kind regards

CSS will not reload a page. I have no idea what xmtl is. If you mean XHTML or xml, I don't think they can do it, certainly not XHTML. If xml can do it though, I don't know enough about it, and the browsers that you are talking about probably have very limited xml support anyway. So my remarks below are as regards javascript.

The problem with refresh on back is that browsers generally will not give you any clue (at lest no relevant clue for this sort of thing) as to how they got to the page, whether it was a fresh navigation to, or as a result of hitting the back button, it makes no difference, except when it comes to running scripts. Several browsers will act as though the script never stopped running and will try to pick it back up wherever it left off. I happen to know that both Opera and FF are like that, but to different degrees, or in different ways. Fortunately for users of those browsers, they usually 'get it right' however they are doing it. IE PC, on the other hand, generally just loads up the page all over again, with a few exceptions mostly having to do with forms, not scripts. Iframe locations are similarly treated differently in the history stack by various browsers. Page designers usually just have to allow for these variations.

As for other browsers (IE Mac included in this), I'm just not aware of what they do. I am also not too sure what one could do to detect which browser is doing what so that action(s) could be tailored on the basis of what the browser is doing, rather than a wholesale refresh on each page load, which would be the only other alternative I can think of. Unfortunately, if you reload on every load, you just get caught in an endless loop of reloading. The way to avoid that is to refresh and append a query (get) variable to the location string and check for that, not reloading if it is present. But, if you do that here, on hitting back, that would be preserved, so the page would do the opposite of what you want, reloading only on a fresh load.

I promise to give it some thought, there ought to be a way, but might not be. At the moment though I can't see any promising approach other than trying to find some condition that is only present in the 'offending' browsers when navigating via the back button that could be tested for using javascript, reloading on the basis of that. Since I don't have those browsers, it would be hard to even imagine what that might be, and there may not be anything. If there were an error given along with the 'freezing', that could possibly be tested for.

waauw thats something else - since one just can hit the refresh button and the browser reloads the page in the cache - I thought there must b a way to do this in a script and refresh the page cache on an event (e.g. on loading a hidden image or div in the body). I didnt think of the loop that occours or that the browser have different manners of loading when hitting the back button/refresh button, in HTML there is even a meta-tag for refreshing the page content.

aha IE on Mac is a terror to make things work the way u want them to work. On the other side; if it works in IE on Mac than it is near to "websafe" ;)

Thanks for giving your advise and help so far and hope to read your thoughts on this issue.

OK, I feel like I am giving you a loaded gun, but in testing here, this appears to work out for Safari and IE. Opera and FF seem to ignore it, sort of, but don't appear to do anything really bad with it.

Both Safari Win 3 and IE 7, and presumably their earlier versions will at least activate a reload of the page to a unique URL (which presumably busts page caching) upon navigating to the page using the browser's back or forward button. Nothing should happen with a fresh page load navigated to in the normal manner. If the refresh button on the browser is hit, various things may happen, depending upon the browser. I have taken precautions to try to ensure though that, under no circumstances will an endless loop of reloading ensue. I may have missed something. If this does happen, use whatever utility you have on your computer to kill the browser instance - stop the browser even though it's busy (in windows that's called task manager).

Here's what you do. Be sure to do both things, otherwise something bad/weird, like a looping reload that you will need to recover from by killing the browser could more easily happen. Put this script in the head of the page:

Code:

---

<script type="text/javascript">
function testForBack(){
if(document.forms[0].elements[0].value=='later'){
document.forms[0].elements[0].value='first';
window.location.replace(window.location.href.replace(window.location.search,'')+'?reloaded='+new Date().getTime());
}
else
document.forms[0].elements[0].value='later';
}
if ( typeof window.addEventListener != "undefined" )
    window.addEventListener( "load", testForBack, false );
else if ( typeof window.attachEvent != "undefined" )
    window.attachEvent( "onload", testForBack );
else {
    if ( window.onload != null ) {
        var oldOnload = window.onload;
        window.onload = function ( e ) {
            oldOnload( e );
            testForBack();
        };
    }
    else
        window.onload = testForBack;
}
</script>

---

Put this markup immediately after the opening <body> tag:

HTML Code:

---

<form style="visibility:hidden;position:absolute;top:-1000px;left:-1000px;" action="#" onsubmit="return false;">
<input type="hidden" value="first">
</form>

---

Okee John I placed the scripy in the <head> and the html part directly after the <body>tag. I can't notice a reload and the images in safari (1.3.2 (v312.6))and Opera (9.24) r still freezing after navigating to a page and hitting the back button. The gun shoots but doesn't hit target it seems ...

You said at first that the only problem browsers were IE and Safari. Now Opera is giving you problems as well?

In any case, things may be able to be tweaked. First let's make sure you have uploaded the code and it is working properly. Do you get something like so (the number should be different each time):

Code:

---

?reloaded=1194635345703

---

added to the filename in the address bar when navigating to it using the back button? (Opera shouldn't, but IE and Safari, the ones I thought you said this problem was limited to, should).

The code is working here (at least to add the numbers) on your main page live. If it isn't there, you still have the old version cached. The only other issue is whether or not it is busting the cache of the page. Since the URL is different, and unique, it should.

Hallo John,

In IE your script works when hitting the back button it gives different numbers in the address bar overhere. In Safari the numbers r'nt showing same in Opera (as you said). So yup the code is uploaded and working.

Well, in IE, has that taken care of the problem? If not, either the unique URL isn't causing enough of a 'cache bust', or reloading the page as a solution was only an illusion.

I forgot to mention earlier on, that just because clearing the cache and refreshing a page, 'fixes it', doesn't mean that carrying out those steps in javascript will.

I'm thinking that we may want to try tapping the:

Code:

---

location.reload(true);

---

method (which is supposed to reload everything from the server), just to be sure, but once again, we run the risk of causing a loop. And, with the reload method, nothing may be appended to the address as a check against looping. Perhaps with two or three reloads/refreshes, it could be worked out to run a course, perhaps not. And, as I say, even we get the type of reload we think we want, it may not solve the problem.

waaah it seems a bigger issue than expected. I realy appriciate your help here. As a n000b I c things more simple than as they r in "real cross browser life". an auto fresh reload from the server could do the trick in any browser but ahum how do I apply this code: location.reload(true); in my script?

Calm down. If we are to move forward, I need you to be like a scientist, faithfully reporting results, or the lack thereof clearly and dispassionately. Have we made any progress in IE? I don't count the numbers being appended to the URL as progress, only if the slide shows no longer freeze upon hitting the back button. So, what happened? I have another idea. But before trying that, figure out if what we already did helps IE or not and tell me.

I wouldn't need to be so 'persnickety' or whatever it is that I am being if I could test these ideas myself, but I cannot. I don't have the machine(s) or browsers that you are using.

Here is the new idea, keeping everything we added to the body the same, use this script instead in the head:

Code:

---

<script type="text/javascript">
function testForBack(){
if(document.forms[0].elements[0].value=='later'){
document.forms[0].elements[0].value='first';
setTimeout('window.location.reload(true)',3000);
}
else
document.forms[0].elements[0].value='later';
}
if ( typeof window.addEventListener != "undefined" )
    window.addEventListener( "load", testForBack, false );
else if ( typeof window.attachEvent != "undefined" )
    window.attachEvent( "onload", testForBack );
else {
    if ( window.onload != null ) {
        var oldOnload = window.onload;
        window.onload = function ( e ) {
            oldOnload( e );
            testForBack();
        };
    }
    else
        window.onload = testForBack;
}
</script>

---

Now, there may not be a solution to this short of using something other than the U-Fade script. I think I have been up front about that from the beginning. But, another avenue would be to work on the server side. We cannot do that if your host doesn't support a server side language and/or you don't have permission to use it. Does your host support a server side language, and do you have permission to use it? If so, which language(s) are available to us on that basis (supported and available to us)?

I should add that I'm not an expert in everything, no one is. Someone else might have a better idea or an entirely different approach. If we can and do decide to use a server side language, I'm not real strong in that area, but it seems to be a fairly straightforward issue, one that could be Googled, if we knew what language(s) we had at our disposal, if any.

Im with u mr. S in IE the probelm isnt there anymore - The freezing of slideshow is occouring in Safari and Opera when hitting the back button. This freezing is random, e.g. slideshow 5 and 2 freez onother time only slideshow 4 freezes (I think at first test in Opera it looked fine Bcause posible a black image freezed).

For this next step here is the test results:
• IE is showing the reloadnumbers in the address bar
• Safari shows no reload in activity/status/address bar
• Opera there is no reload showing in the status/address bar
• FireFox is reloading the page one time after hitting the back button
• Netscape is reloading the page one time after hitting the back button
• Flock is reloading the page one time after hitting the back button

The following languages r available 2 us on me hosting server 4 server-side scripting: •ASP/ADO •SQL •PHP

I will make a testpage using Ur swissarmy script to c whats the effect when hitting the back button, u will read about the results - my mentor ;)
your help in this is more than appreciated sir and its a good cause to find a solution everyone can use eighter on a browser-side or server-side way.
As u must have noticed my skills r zero to zip in scripting but its fascinating 2 make an effect on the web 2 work 4 everyone to c. i googled b4 i found this forum with no realy working result. so start at the source I thought ask the expert who created the script.

In addition 2 my other relpy:

With the swissarmy script the following results came:


• IE is not showing the slideshows
• Safari some images freeze random after hitting back button
• Opera some images freeze random after hitting back button
• FireFox works perfect
• Netscape works perfect
• Flock works perfect

OK, I'm thinkin'. I'll get back later when I have more time. I think though, we will have to (if it's possible) go to the server side and reload the page once for any browser every time.

Hi John, do u have an id yet how to do this?

I have looked into it somewhat. So far there doesn't appear to be any easy way to do this on the server side (at least not for me), and no other client side solution has occurred to me.

I'm fairly sure that using an incremented/decremented server side variable could work, but I'm not much up on the server side languages. My concept is this:

The page loads with this variable set at 0.
Since the variable is 0, it is set to 1 and the page is reloaded.
Since the variable is 1, it is set to 0 and the page isn't reloaded.

I really am not certain if there even is a way to reload server side, or if there is if there is time to check and set variables first, server side languages can be tricky in that regard. If those are not obstacles, then it would work, the result being that the page would always load twice in all browsers. Kind of like killing an ant with a sledgehammer, but if that would solve the problem, I suppose it wouldn't be too bad.

Generally, using the back button is not how folks navigate a site anyway, and this problem appears to happen only in browsers not generally in wide use. I would be most concerned about Opera, but it really isn't that widely used, and most devotees of it are aware of how it doesn't fully load a page upon hitting the back button, so are used to refreshing on their own if things look odd at that point.

I vote for either ignoring the browsers that have a problem with this or using Flash instead.

Thanks very much for your expert advice, John. Unfortunatly I'm a bit of perfectionist on how my sites work, cross platform and browser shouldn't b an utopia or unreachable with the state of the art technics - so this is a good reason to start with flash instead of learning scripting in php, java-scripts or so (for me). When finished I'll post here the link to the results of the website. Again many thanks for your time and advice.

Patje

I hope I haven't lost your attention yet because I think that there are other things to consider. Being a perfectionist isn't all that it's cracked up to be, and we (I'm somewhat of one myself) can sometimes be too easily swayed by what may seem like problems and solutions.

You say your goal is to be cross browser. What does this mean? No complex page will work down version in all browsers, there are simply too many incompatibilities in the way browsers work over their histories. The good news is that virtually all current browsers adhere closely enough to the standards that most things written with those in mind look at least OK in all of them. That's being cross browser.

The web is not a magazine or a TV. You cannot expect your content to play exactly as printed/taped. There have been several (probably more) techniques invented over the years to try to get that effect. They all fail because in their rigidity, they let some user agents fall through the cracks. They don't account for the old, they don't account for the new, they don't account for people without the plug in, or they don't account for the capabilities of a given system, aside from the browser and plug ins in use on it. Or they account for none of these things.

Now what you are doing is high end. However you choose to do it will leave out some low end users. So the trick would be to find a way to do it that reaches the most user agents in an flawless manner, second most in an acceptable manner while degrading gracefully in as many others as possible. Without extensive statistics on your site's usage, that is impossible to know with any certainty. It can generally be assumed that what you have already is very close though. If you go to Flash, it will solve the issue for some while creating problems for others.

Flash may still be the way to go for you, but it will leave out all dial up users, many with slower DSL connections, and those without the plug in unwilling or unable to install it.

You should take some gauge of your audience and of your target audience. If they are all upscale with high end machines, Flash is a pretty good avenue. But so it what you are already doing, and that present method will be accessible to more down end users than will Flash.

yeah there is food for thought - but r there still so many people dialing up for connection? and r these my target-vieuwers - but a site should work on any browser with as less posible differences in appearance - i know about the differences in type and colour in the different browsers and platforms so thats already a thorn in the eye ;).
Still what can one do else than use strict codes of the W3 organisation? xmtl with css, mayb supported by javascripts, php and asp for codes and the expertise of good people like u. It would b great if there is a way to avoid plug-ins and other extensions 4 browsers to b down-loaded b4 vieuwing the content of a site, frankly speaking i myself loose intrest when hitting one of these sites. That brings me back to the issue how 2 solve this strange effect of freezing images. Ive noticed that when hitting the links the slideshows work all fine. Nice puzzle ha.

I can say from knowledge of the subject, that in the case of Opera, it was actually designed to favor speed over (among other things) the rendering of complex scripts on page reloading from the back button. Folks who choose it for that reason sooner or later become aware of the issue and refresh as needed/desired. Other Opera users may be mystified, and a bit disappointed at this behavior. Opera is evolving and now does many things it did not once do, in effect gradually mainstreaming itself while still trying to maintain optimal speed. It's doing a pretty good job of this, so this back button issue may be 'fixed' (rather changed, actually) in it at some point.

As for other problem browsers, they may simply be outdated, or there could be other reasons I'm not aware of.

If what you are doing isn't essential to the content of the page, this hardly matters much. Scripts (and all other non text only content) should be used in full knowledge of their limitations, which are several. In all cases, a page can be made to render acceptably as text only if no other technique can be made to work properly in a given user agent. It is a matter of opinion if this should always be the goal. It clearly will not leave behind an overwhelmingly number of users if it is not, but that's not always the point, and sometimes those users are actually the target audience. One really needs to judge for oneself what to do. Some scripts lend themselves more easily to degrading if unsupported, but one can always devise a way to avoid problems from them in user agents that don't support javascript. It is in the area of partial support where things get tricky and either some compromises must be made there, or one must do extensive testing and usually modification to be assured 'all is well' in that area (the goal there being to either do the script as intended, or to have the user agent skip it). That is generally considered too extreme for most developers, and can require either a complete redesign, or the use of 'browser sniffing', which must be monitored on an ongoing basis to make sure that it isn't failing to perform as desired as newer user agents are released.

I find it most helpful to realize that the web is a fully protean medium and that one basically just has to take one's 'best shot', and be wiling to update as needed. In fact, it is generally best to overhaul a site periodically for a 'new look' anyway.

Getting back to the original question, I found this in another thread:

PHP Code:

---

<?php
session_start();

$_SESSION = array();
session_destroy();

?>

---

This supposedly will force the browser not to cache the page. If so, it may be a solution. I imagine it must go near the top, if not the exact top of the page. If it is at the exact top though, before the DOCTYPE, it may interfere with DOCTYPing in IE.

I've little knowledge of this technique, it may also mess up something else with your set up, like if there is any other stuff that depends upon the session remaining intact. But it also looks like it may be creating and destroying a session, perhaps leaving others intact.

If you want more information on it, Google or post in the PHP forum.