JAVA Rollover

[inTUITIVE]

I need to get some help with a JAVA rollover script. We currently have pages including this script and they work fine locally in either Netscape OR IE. When we place them in our main domain, they also works fine. If we place these same pages in our IRM (redirected domain) it fails to work right in Explorer. Again, locally Explorer works. Why does the IRM cause it to fail? If anyone wants to look at the script the main domain is www.intuitivenet.com. The IRM is www.bhsdenver.com. So the two different business can stay online, the pages are not the same. Please keep in mind that either can be interchanged within the two domains and only the IRM (bhsdenver) fails. Can someone help? Although its a HUGE pain, I have tried some other scripts and they ALL fail. If I cannot resolve this I'm going to have to make some undesired changes.

[hearts]

Hey, I am not a java script expert by a long shot, but I am comparing the two codes to see what the difference is between the two sites, here is my observation:

at www.intuitivenet.com/ (http://www.intuitivenet.com/) there is a listing of individual preloading of images. example of your code to what i am referring to:
<script language='JavaScript'>
<!--
MM_preloadImages('images/serviceson.gif');

this page works great in both MSIE and Netscape

------ other page --------

at www.bhsdenver.com/ (http://www.bhsdenver.com/) you don't have the listing of preloading images.

the images work, but are delayed quite a bit only in MSIE.

So, my feelings are, if ya apply the same type of coding that you did on the first URL to this site, you will accomplish what you are seeking!

Post and let me know if this was right?

-------------
hearts
-----

[This message has been edited by hearts (edited 04-08-99).]

[inTUITIVE]

Good try but it didn't work. If you notice at the bottom of the html you will see those preloads. My staff has told me that as long as the page loads fully it doesn't matter that those commands are at the bottom. I guess that was done to help compatibility issues regarding another JAVA applet. Anyways, I personally moved those commands up per your suggestion and no dice. Remember, I have taken the site you mentioned (www.intuitivenet.com) and tried to run it under www.bhsdenver.com and the rollover stopped working. Also, if I access the current page via www.intuitivenet.com/bhsdenver then it works fine. Ahem. Thanks anyways!

[Deb]

hrrrmmm...

We're also looking a bit deeper into it... it seems everytime I put my mouse over the image it is actually calling the image from the server again rather then from the cache... strange indeed.

Another suggestion that Justin had that may work is to put the slash in front of the path... ergo rather than images/image.gif try using /images/image.gif (also try full url in the code just to rule out everything if the / alone doesn't help) and see if that in fact helps at all....

Once Andrew is back from upgrading SIX he'll probably dig back into this one... I am not able to see off hand how the rewrite rules would be affecting it....

Deb

[hearts]

then all i can reccommend is try using the complete path of your images. Infact, I would try it using this www.intuitivenet.com/bhsdenver for your images and see if that doesn't help clear things up.

IN netscape it worked fine, and it has something to do with your images preloading. Maybe it has something to do with the internal redirect.

good luck.

---------------
hearts
-----

[Terra]

Drum Roll please:

ergo rather than images/image.gif try using /images/image.gif

You will need to call the images via:
/images/image.gif

You must use the leading slash, or the fully qualified URL as Hearts has mentioned...

If you just use 'images/image.gif' then it forces Apache to jump through 9 kinds of hoops to figure out what you are trying to do thusly causing your browser to call that image each and everytime you hover a rollover...

Please let us know if this solves your situation...

--
Terra
sysAdmin
FutureQuest

[inTUITIVE]

I modified the html to include the '/' so all applicable calls look like /images/xxx. The page I modified was index.htm and is currently online. That didn't seem to resolve the problem. For some reason it still tries to load each image everytime you roll over the image. It Doesn't work to bad on a T1 however ISDN or lower and its very apparent. http://www.aota.net/ubb/frown.gif

[Terra]

I am working on this problem as well... You will notice a mirror index.htm-Terra that I have created as well...

The behavior of this is very peculiar... For some reason IE4 does *not* want to cache the images, which this rollover is dependent on and forces the image to be fetched from the server every time...

I have gone down to the HTTP level, with an ethernet sniffer (raw packets of communication) and have not been able to find anything peculiar... I have tried it through both a squid proxy and without... Somehow IE is seeing through the IRM and forcing a 'Referer: ' line on the request...

I will continue to work on this problem, but don't see a solution at the IRM level, as nothing is apparent...

I believe that setting your <IMG SRC="http://www.intuitivenet.com/bhsdenver/images/xxxxxx.gif"
will solve the problem temporarily, as IE will cache this...

In Netscape, everything works fine... This may be one of those quirky behaviors that are inherent in every browser, and this particular situation afflicts IE4...

There are many other domains using rollovers with IRM's, and are not exibiting this behavior with either NS or IE... To be honest, I am just not 100% sure if this is a Javascript problem that somehow amplifies this IE4 problem with given set of conditions, or if it is in fact a problem with the IRM setup...

In the end, it is difficult to always adjust the servers to match all the browser incompatibilites out there, as we try to follow the RFC and industry standards, to find that fine thin line to be everything to everybody...

I will continue to investigate this, as it has me very intrigued... I can almost guarantee that it will result in a server 'kludge' to make it react with your desired behavior...

Try the above suggestion, and see if in fact the images are forced into your browser cache..

--
Terra
--Why can't we all just get along???--
FutureQuest

[hearts]

okay.. i have one more suggestion.. and please see if this will work. This will keep you from having to edit the images...(place this above your <HTML> tag)

<base href="http://www.intuitivenet.com/bhsdenver/">

what you will need to further do so your URL location will show the redirected domain is call upon each link <a href="http://www.bhsdenver.com/whatever.html">

Alteast try this.. as I view this as a internal redirect problem. A good one to torment Terra's brain! *grin*

-------------
hearts
-----


[This message has been edited by hearts (edited 04-12-99).]

[penelope]

From what I've been given to understand, there is a bug in DCOM that causes caching to be buggered up. I posted in MS beta newsgroups about this before it was released, and it got out anyway.

I have had to completely redesign the BB Dev site I was working on because of this. The trouble is that the problem isn't always there. I'd say roughtly only 50% of the people who upgrade experience it and we can't seem to find any tried and true reproducer..

Peace,
Penelope

[penelope]

here is the extremely long reply I got about it...

Hi, Penelope. MSIE Cache Management efficiency (going to-cache rather than redownloading) has been affected in
the past by the installation of different versions of DCOM.

In my experience, when a newer version of DCOM is installed on any W9x system, MSIE Cache Management efficiency has improved.

Furthermore, MS have bundled many of their DCOM updates along with the MS Java Virtual Machine updates. (You don't even know you're installing a DCOM update unless you look closely at the install-progress-screen
during the JVM installation procedure.)

Normally, a DCOM update version can be checked by looking for a C:\Windows\System\dcom95 folder
(for W95 systems). One of the Readme files in this folder will tell you which version of DCOM is in use on that system.

So far, the latest DCOM available for W95 is DCOM 1.3. It is my understanding that a newer DCOM was supplied with W98 and with MSIE5 -- However I don't know enough about this to comment with certainty.

For more info about DCOM, see the DCOM website at: www.microsoft.com/com/dcom.asp

For details on DCOM 1.2 (latest public info of which I am aware) see the DCOM 1.2 website at:
http://www.microsoft.com/com/dcom/dcom1_2/default.asp

There is important info on that website about the various versions of DCOM and their implications for W95 and W98 users.

Please note that MS has bundled a silent-update to DCOM 1.3
in with the latest JVM update for W95 users of MSIE4. I have not seen any detailed info on what bugfixes are implemented
between DCOM 1.2 and 1.3, (other than the readme files in the DCOM95 folder) but I do know that 1.3 improved Cache Management Efficiency on MSIE4.01 SP1 when I first
installed the new JVM that contained DCOM 1.3.


Sue Fisher has already mentioned in one of her posts that the latest update to MSIE5 has improved (but not completely fixed) the Cache Management inefficiency found in MSIE5.

You might wish to investigate an MSIE4 SP1 installation on a W95 machine where DCOM 1.3 is installed -- versus an MSIE4 SP2 installation -- versus an MSIE5 installation, to see if the MSIE4 SP2 installation has the same problems as MSIE5. If so, you've definitely proven that the updated
DLLs used in MSIE5/MSIE4-SP2 are the problem.


If MSIE4-SP2 works similarly to MSIE4-SP1, then something unique to MSIE5 is messing up the works, but only on *some* machines. Next step is to check the MSIE4-histories on those
machines, to see which version of DCOM was installed on that machine before MSIE5 was first installed.

For example, I have *religiously* installed DCOM 1.2 on any machine I've worked on, *before* installing MSIE4 and the
updated JVM that contains DCOM 1.3. This has always produced a noticeably-more-stable MSIE4 installation in my experience -- even before the release of MSIE4-SP1.

I suspect the DLL-installation-history will be different between machines running MSIE5 with high-efficiency Cache Management
versus machines running MSIE5 with low-efficiency Cache Management.

Consequently, I suggest you ask for information about the situation
*before* MSIE5 was installed to know what is "golden" about the machines running MSIE5 with high-efficiency Cache Management.

Hopefully, something in the above will be of help.

Best I can do for now. <tm>

Bill
bdrake@direct.ca