Netscape JavaScript Error

Ticker won't run when location bar shows only the domain name

[pchristensen]

For some time now, I have come to live with a problem that one of my sites has with Netscape (all recent versions, including 7.1).

I use a scrolling JS message ticker on the index page and the only way that Netscape resolves the script is when the "index.html" appears after the URL. In essence,

[widgets.com...]

..produces no ticker...just a plain white background where the text should scroll. On the other hand...

[widgets.com...]

..produces the scolling text just fine. The site is 100% W3C 4.01 compliant and all versions of Microsoft IE run just fine with it.

At one point, I did an immediate re-direct in my index.html to a dummy index file at "index-2.html" and that worked fine but the extra load time was a real problem no matter how fast I forced the re-direct.

So, any suggestions on how I might force Netscape read and display "index.html" from within the index.html code without cuasing any unecessary page load delays? Thanks!

[MonkeeSage]

Put this right before the closing body tag (</body>) at the end of your page:

<script type="text/javascript">
<!--
 var loc = window.location.href;
 if (loc.indexOf("index.html") == -1) {
  if (loc.charAt(loc.length-1) == "/") 
   loc += "index.html";
  else
   loc += "/index.html";
  window.location.href = loc;
 }
//-->
</script>

This will check if the href of the page has the string "index.html" in it, if not, it will check for a trailing slash, and then append index.html accordingly. If it find index.html in the href (e.g., on the second load, or if index.html is explicitly entered in the URL bar or clicked from a link), it will do nothing. The delay time should be literally only milliseconds.

HTH
Jordan

Ps. At some point you might want to actually debug the scroller and figure out what is going on. If the above is not a viable solution for you, I'll be glad to try and help you track down the source of the problem.

[MonkeeSage]

Actually put it right before the closing head tag (</head>), no reason to wait for the whole body to load in this case (I'm used to use open scripts like that when I need to access something on the page just after it loads, that why I said put it at the end of the page, but in this case there is no need and it just makes things slower).

Jordan

[pchristensen]

Monkeysage:

That last suggestion fixed everything and there isn't even a glitch on the load in either browser....I guess that's because the correction is occuring before the body page load. What a great solution!

Paul

[pchristensen]

One final thought...will the search enginers view this negatively as a site re-direct...even though the re-direct is the same page (i.e., index.html)?

[MonkeeSage]

Paul:

Hi there, I just saw your sticky note from the other day, I'll reply to that in a little bit. Didn't mean to ignore you! I need to start looking up at the top there more often!

As to your question, this would only be a problem for the SEs if it took the user to a different page than it showed to the spider. In that case it would be considered cloaking, and would be frowned upon.

But in this case, as I understand things (someone else will correct me if I'm mistaken, I'm sure), they would look at the base URI and the href we built and would see that they are the same page, and all is well. :)

Jordan