Closed Bug 178177 Opened 23 years ago Closed 22 years ago

javascript animation continually loading

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: geophi, Assigned: asa)

References

(
URL
)

Details

User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.2b) Gecko/20021016 Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.2b) Gecko/20021016 In the above page, the javascript satellite animation never gets completely loaded. The 10 frame loop never has more than 5 or 6 frames in it, and there is continual "network" activity, incoming and outgoing. This is with JRE 1.4.0_02, if that has any bearing. It works fine in IE6. All satellite animations at that site show the same behavior. Reproducible: Always Steps to Reproduce: 1. Load the page 2. Wait for awhile and the animation never completes 3. Actual Results: The loop never fully loaded, and continual network activity occurs. Expected Results: Finished loading the loop.
wfm using Phoenix 20021103 on Win2k, I see 10 frames. What is your cache setting ? btw, site is not using any Java. I've seen the same exact bug already reported in Bugzilla but can't find it for now.
Assignee: idk → asa
Component: Java-Implemented Plugins → Browser-General
QA Contact: avm → asa
site uses jsImagePlayer: http://sgi.felk.cvut.cz/~xholecko/player/index.html, similar to bug 127825. Could be dupe of bug 110048.
Hardware: PC → All
cache settings are in both Linux and WinME are: Memory cache 4096 KB Disk cache 50000 KB Compare page when page is out of date.
do you still see < 10 frames when cleaning cache and reloading site ? It still wfm using Mozilla 20021103 on Win2k.
I still see the same behavior after clearing the cache's. Although it is odd that there appears to be no disk activity when I clear the disk cache (both in WinME and Linux.
Reporter (George): Can you reproduce this bug with a recent build of Mozilla (for example, 1.3a)? If so, then please comment again with details. If not, then please resolve this bug as WORKSFORME. Thanks.
With Mozilla 1.3a, certain javascript animations continue to act as described in the bug report. For example, at http://weather.cod.edu/satellite/southcentral.mbirloop.html or at http://www.rap.ucar.edu/weather/satellite/displaySat.php?region=ICT&isingle=multiple&itype=ir the loop will never fully load, and network activity shows both sending and receiving occurring almost continuously. I thought perhaps it had something to do with my restrictive settings in the Preference/Advanced/Scripts and Plugins. However, allowing javascript to do all those things still resulted in the same errant behavior. These animations worked as expected in IE6 and Netscape 7.01. Do you have any suggestions about other Preferences that might affect this?
In comment #7 I stated that it worked in Netscape 6 and 7.01. My mistake. The animations appeared to have worked, perhaps because the machine I am running it on is such a fast machine. However, leaving it on that page for awhile, it still results in continuous network activity in attempting to load the full loop. What initially appeared to be a full loop, soon ends up being 2 or 3 frames. So for a K6-III+ 450 with 256 MB of RAM running WinMe and Mozilla 1.3b 20030214, and for an Athlon XP 2400+ with 512 MB of RAM running WinXP and Netscape 7.02, the bug behavior continues. Example, loading http://www.rap.ucar.edu/weather/satellite/displaySat.php?region=ICT&isingle=multiple&itype=ir the first frame, and maybe frames 4 and 5 of a 9 frame loop will load. In the Mozilla window Status Bar, frequent, nearly continuous status messages are written. "Connecting to www.rap.ucar.edu..." "Connected to www.rap.ucar.edu..." Repeat the above several more times "Done" then repeats the above status messages over and over. At the same time, there is network activity indicated in ZoneAlarm firewall program. Loop loads fine in IE6.
I am also trying to create a reliable Javascript animation, in an endless cycle. After a week of web log studying, I have the following impressions: The "image reload problem" happens accross all browsers. I have seen log entries both from Mozilla as well as IE 6, and it seems to be general problem between Javascript Image objects and the browser's image caching system. In general, I distinguish 3 cases of behaviour. Let's say we have an example Javascript code like this: // preloader part preloaded_image_1 = new Image(); preloaded_image_1.src = "frame1.jpg"; ... // animation part doc_image.src = preloaded_image_1.src doc_image.src = preloaded_image_2.src doc_image.src = preloaded_image_3.src 1. Then case ONE, "everything fine", looks like this in the log: ip.ip.ip.ip - - [date] "GET frame1.jpg HTTP/1.1" 200 12345 ... ip.ip.ip.ip - - [date] "GET frame2.jpg HTTP/1.1" 200 12345 ... ip.ip.ip.ip - - [date] "GET frame3.jpg HTTP/1.1" 200 12345 ... [END OF LOG] That is 1.1. all images are loaded once - no further log entries, even while animation is played 1.2. the images are loaded completely (provided, in this example, they have a size of 12345 bytes), with RC 200 2. Case TWO, "permanent re-check", looks like this: ip.ip.ip.ip - - [date] "GET frame1.jpg HTTP/1.1" 200 12345 ... ip.ip.ip.ip - - [date] "GET frame2.jpg HTTP/1.1" 200 12345 ... ip.ip.ip.ip - - [date] "GET frame3.jpg HTTP/1.1" 200 12345 ... ip.ip.ip.ip - - [date] "GET frame1.jpg HTTP/1.1" 304 - ... ip.ip.ip.ip - - [date] "GET frame2.jpg HTTP/1.1" 304 - ... ip.ip.ip.ip - - [date] "GET frame3.jpg HTTP/1.1" 304 - ... ip.ip.ip.ip - - [date] "GET frame1.jpg HTTP/1.1" 304 - ... ip.ip.ip.ip - - [date] "GET frame2.jpg HTTP/1.1" 304 - ... ip.ip.ip.ip - - [date] "GET frame3.jpg HTTP/1.1" 304 - ... [ENDLESS REPEAT OF 304 RECORDS] That is 2.1. images are loaded initially, complete and correct (RC 200) 2.2. but when animation is played, browser re-checks every frame, permanently, through HTTP requests - however without actually re-loading the image files, as they don't change. Nevertheless, the requests are superfluous, and may already create performance problems. 3. Case THREE, "permanent re-load", looks like this: ip.ip.ip.ip - - [date] "GET frame1.jpg HTTP/1.1" 200 12345 ... ip.ip.ip.ip - - [date] "GET frame2.jpg HTTP/1.1" 200 12345 ... ip.ip.ip.ip - - [date] "GET frame3.jpg HTTP/1.1" 200 12345 ... ip.ip.ip.ip - - [date] "GET frame1.jpg HTTP/1.1" 200 12345 ... ip.ip.ip.ip - - [date] "GET frame2.jpg HTTP/1.1" 200 12345 ... ip.ip.ip.ip - - [date] "GET frame3.jpg HTTP/1.1" 200 12345 ... [ENDLESS REPEAT OF 200 RECORDS] So 3.1. images are loaded during preload phase 3.2. images are re-loaded during every animation cycle, as if the browser cache was disabled As far as I see, case 1 happens in 60% of the times, case 2 in another 30%, and case 3 in another 10%... just my first results after a week of research. The cases are distributed randomly accross all kinds of browers. Furthermore, 4.1. it is my impression that the "Image.complete" property is NOT implemented correctly in Javascript - on every browser. Every image instance immediately flags "complete" after STARTING to load, NOT after completing the load. 4.2. if the browser re-loads an already loaded image, for what reason whatsoever, the "Image.complete" property is NEVER reset. So the Javascript developer has no chance either of detecting the "re-load" condition, nor of any performance measurements. I think Javascript has no clue what the browser's image cache is actually doing. TEST CASE I can reproduce a permanent re-load with Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020826 this way: 1. go to a website with an endless javascript animation 2. wait until it's loaded and running 3. go to "Preferences->Advanced->Cache", then Clear Memory Cache, and Clear Disk Cache 4. i would expect that Mozilla is re-loading the images ONCE now, and proceeds with the animation. instead, the browser runs into endless reloads. This is just to show how the reload looks. I don't know how the "real-life" reloads from the internet happen, but i cannot imagine that any surfer actually switches off his cache.
The URL provided is now a dead link, but http://weather.cod.edu/analysis/loops/radloop.master.pl?illinois looks like it is something similar. I somewhat see this problem, in that on this page, the images do not seem to load correctly at first. Each time through the animation loop, one more picture is loaded until the 12th cycle when they are all finally loaded. After that, the animation plays as expected and there is no more network activity. I don't know enough JavaScript to be able to say with any certainty if this is a bug in the site's code, or in Mozilla. Can anyone else confirm the original bug still exists? Do you still have the problems you reported Vincent? Thanks for any new information.
Worksforme with a 20031123 build on WinXP. Very old bug -> WFM
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.