When you pass the mouse over the buttons of the top of the page ( over three buttons for example the next after the previous directly ), it freeze the complete browser.

I'm not seeing this on Linux Mozilla 1999-11-29-08-M12, but loading this page took a very long time (90 secs.) and repainting it when I re-exposed the browser window took a similarly long time.

Mousing over the javascript-enabled site-navigation buttons on the page at the URL does not freeze up, hang, or crash the browser. The mouseovers are slow to respond, however... if three or more are moused over in a second, only the first and last show the alternative button image at all. Also, CPU usage jumps to 50% from 7% while exercising the mouseovers in Mozilla, compared to jumping to 15% from 7% using Communicator 4.7. Repainting of the page after minimizing the Mozilla window did not take a noticeably lengthy time. Tested with: 1999-12-15-08-M12 nightly binary on Windows NT 4.0sp3 Changing Component from "Browser-General" to "Javascript Engine" based on the performance problems seen here. Changing Summary from "javascript buttons freeze browser" to "very slow, cpu-hogging mouseover of javascript buttons"

Reassigning to DOM component.

*** Bug 7550 has been marked as a duplicate of this bug. ***

Bug 7550 "Mousing over Javascript pre-cached images is ludicrously slow", marked a DUP of this bug, seems almost identical to what I saw testing bug 19550 "Cached images", which was marked a DUP of bug 13325, "js rollovers acting really weird on this site" ... the latter is currently focusing on display problems associated with js button rollovers. Looks like this is the bug for performance problems with js rollovers, and 13325 is the bug for display problems.

Shaver, I know you're planning to do some performance analysis related to mouseovers and animation. Care to hold on to this bug while you're investigating?

Yeah, and I think Michael Lowe has some goodness on this front too.

I think this will get better with the fix to 21879.

It's extremely slow on linux as well. (2000-042113-M16) sample: Left menu-buttons at http://www.linpro.no Moving cursor from *over* the menubar till beneath it, fairly slow, doesn't trigger mouseovers at all. (Triggers instantly in NC4.7)

How come this is still M14? M14 is already out!

M15 is out, too. Therefore, I am now moving it out to M16 for us all.

Tested with Build # 2000060408 On Win 98 SE It did get better with fix to bug 21879 On mouse over button instantly changes to alternative image (button changes from grey to blue). Speed of change is same as NN 4.72 Works for me

Sweet, sweet news indeed. Can anyone verify on other platforms (one Unix and the Mac), before I mark this baby closed?

Linux M16-2000-060420 - about the speed of things.. It's now way faster than it was, but on a P120 it's still some 5 to 10 times slower than NC4.7. In NC i can't move cursor fast enough over the images to avoid them reacting to the mouseover and change pic. When i do it in Moz now, i can still move around quick enough to avoid triggering mouseover at all. So fluent it is not, but a vast improvement - it used to take over a second before a small rollover-button gif appeared.

Any chance we could get somebody to minimize a test case here?

M16 has been out for a while now, these bugs target milestones need to be updated.

*** Bug 43592 has been marked as a duplicate of this bug. ***

Try this URL: http://soros.ath.cx It brought my entire Win98 system to a screeching halt! (not that it's that particularly difficult to do) Changing Milestone since M16 is out. If M17 is unreasonable, please change. Chaning Severity due to effect of the above URL on my system.

taking from shaver for now

*** Bug 46072 has been marked as a duplicate of this bug. ***

The problem here is really the cache. The cause of the slow mouseover is that Mozilla is making an If-Modified-Since request every time the mouseover event fires. This is obviously the wrong behavior. If you have a local caching proxy on your LAN, you might not notice this problem. But if you turn the proxy off and access something on a slow link, it is definitely obvious. Here's the behavior that I observe: 1) Start Mozilla 2) Go to http://www.poet.com/ 3) Mouseover the IMG links in the banner. Everything is OK 4) Hit Reload 5) Mouseover the IMG links again. Performance is very slow and you can use tcpdump or sniffit or similar to observe the constant If-Modified-Since HTTP requests. I don't really believe that this belongs to the DOM 1 crew. It is the cache behavior that is inconsistent and wrong. CCing neeti@netscape.com, and leave it up to neeti to reassign to Networking: Cache if I am right.

seems bug 47767 is another dup

*** Bug 47767 has been marked as a duplicate of this bug. ***

Nominating for nsbeta3 consideration as image rollovers are widely used on the web. We're seeing this on moviefone.com (see DUP bug 47767 for the URL) which although not a Top 100 site is a major AOL property.

Pam, I find that the channel has FORCE_VALIDATION attributes, when they are checked in the CheckCache() method (in nsHTTPChannel.cpp file), which causes doIfModifiedSince to be set true, and we are making the If-Modified-Since request every time the mouseover event fires. On tracing through the code, I find that we are setting the imglib_attribs to DONT_USE_IMG_CACHE in the IL_GETImage(..) method at line 2128. else { ic->forced = FORCE_RELOAD(cache_reload_policy); } Now, when we have the imglib attributes set to DONT_USE_IMAGE_CACHE, we set the channelload attributes to FORCE_VALIDATION, at line 770 in nsImageNetContextAsync.cpp. case DONT_USE_IMG_CACHE: (void)channel->SetLoadAttributes((nsIChannel::FORCE_VALIDATION) | flags); break; I think, we should not be doing a FORCE_VALIDATION everytime we have DONT_USE_IMAGE_CACHE. There could be two cases, where we might not be using the image cache, 1. If the channel passed in already has one the following attributes set nsIChannel::FORCE_VALIDATION, nsIChannel::VALIDATE_ALWAYS nsIChannel::INHIBIT_PERSISTENT_CACHING, nsIChannel::FORCE_RELOAD, then we should be doing a FORCE_VALIDATION, 2. If either of the above 4 attributes are not passed in, and we are not using the image cache, then we should not be doing a FORCE_VALIDATION, instead we should be a doing a "loadNormal" Neeti

N: I removed the switch statement in nsImageNetContextAsync.cpp (that sets the channel load attributes at around line 770) last week. It was wrongwrongwrong. And its gone. The line where the force_load = 1 and the imgloadattribute is set to DONT_USE_IMGCACHE, only happens when the image container is brand new. Try updating mozilla/gfx/src. and let me know. -P

I updated my tree. The channel does not have FORCE_VALIDATION attributes set, instead it's value is zero. I still see that we are making the If-Modified-Since request every time the mouseover event fires. Pam, shouldn't image URLs be also following the user pref settings, VALIDATE_ONCE_PER_SESSION, VALIDATE_ALWAYS, VALIDATE_NEVER? In the case of non image URLS, these attributes are set on the channel in nsDocShell::DoChannelLoad(..) method. Neeti

Reassigning to myself.

*** Bug 29186 has been marked as a duplicate of this bug. ***

--->Pam

Checked in a fix. If we were given a LOAD_NORMAL from the defchannel, the LOAD_NORMAL should be modified by the preference values for how often a page is validated. -p

Reopening due to http://soros.ath.cx still being EXTREMELY slow in processing rollovers (this was bug 43592, marked as a dup of this one). Once the page loads (which takes forever, see bug 54542), JS rollovers take several seconds to respond, and often only the first and last happen on a move across several. Cache settings are Once Per Session. The slow response might be a layout/reflow issue, though, as I note in 54542. Changing URL to http://soros.ath.cx

I confirm this regression. On the original URL http://www.poet.com I can see using tcpdump that Mozilla is making in If-Modified-Since HTTP request on every rollover. If I didn't have a squid cache I would have been hammering the remote server. Making this visible with RTM nomination. This should be fixed ASAP.

Sounds like we might want to reopen 29343 (or 21137, to which it was dup'd, but that one doesn't really seem appropriate).

gee whiz shaver, lets just keep reopen one bug until we figure out whats going on, ok?

geez, pnunn, it sounded to me (from two independent reports) that we weren't honouring the pref -- which is what 29343 is about, right? Why do you object to reopening that bug? Do you dispute that the problem described in that bug (and noted here) is occuring? (Even if it should be hitting the image cache, as fur and others since have asserted, it should _definitely_ be hitting the network cache before it goes out on the wire.)

sorry, shaver. Just a bad morning. And I wanted to keep a wave of bug reopenings from happening. Something changed that affects reloads. I don't know of any changes in imglib that could affect it, but I'm not ruling it out. dp made changes in httpchannel that probably doesn't affect this, but might. And I've heard tell that frames aren't inheriting the parent load policy correctly. -p

quick status: I've checked that the necko cache changes are working as expected with its requests from the imglib(anims). And no one has pointed out that the page http://soros.ath.cx/ is a bit pathological. There are what, 767 images on the page. and you want them all preloaded? Yes. its slow. -------------------- And what is similar with the www.poet.com site? I haven't started looking at that yet. There are several places where the reload can be wiggled: prefs, necko cache, imgcache, animation reloads, frame load policy, top doc load policy. -p

The netwerk cache holds only 512 entries. Once it reaches this limit, it starts deleting not entries which are not in use. If it cannot delete any of the 512 entries, i.e all of them are in use, as in the case of http://soros.ath.cx(767 images), it stops caching these entries, until some entries can be deleted.

Okay, please ignore the soros.ath.cx, because it is a pathological edge case. However, http://www.poet.com is a very typical use of rollovers. On every rollover, we are contacting the origin host. This is very bad, and it isn't because the people at www.poet.com are being assholes.

Better data point: http://xml.apache.org/ When you mousover the sidebar on that page, you make an if-modified-since request and get a not modified response. Worse, if you mouse up and down the sidebar very rapidly, the images will start disappearing. They are replaced by their ALT attributes, which tells me that Mozilla has decided the images couldn't be retrieved. I am attaching the filtered output of tcpdump. I loaded http://xml.apache.org/, then I moused over and out of the "contact info" image five times slowly. This resulted in ten HTTP requests.

thanks for the info, jb. I'll dig into why we think the caches are not fresh. Animated images aren't cached in the imgcache yet (I'm working on it). But it should be in the netlib cache. I tested this and it works fine. Be aware that once you have clogged up the netlib cache by hitting its limit of 512, there is a bug where the cache manager doesn't update the number of total entries after it has purged some. So you won't be able to cache any new items. I don't know the details, but neeti has a bug on it and is working on it. If your results here could have been affected by the above scenerio, let us know. -pn

There is a special case in netwerk cache, when we stop using the cache after 512 entries. See bug 54630

How can we get some PDT love on this bug? If 6.0 goes out with this bug, most website operators are going to shitlist Mozilla. We have to at least be good net.citizens.

Dare I ask why this bug is nsbeta3- when nsbeta3 has long since hit the wire?

It looks as though the patch to 56599 has fixed this bug, or at least changed its behavior. I no longer see HTTP requests being made to the origin server when a mouseover fires at http://xml.apache.org/. Marking WFM.

Mozilla may not be hitting the network on Mouseovers, but the links on the left side of the page are very sluggish and CPU-hogging on my Athlon 700! Is this really WFM?

It certainly worked for me on the latest trunk build on Linux, 2000-10-25-08. My cache is set to "Once per session". Are you having a contradictory experience?

Sorry if I wasn't clear . . . On my system, Mozilla is *not* making HTTP requests to the server on mouseovers. If making HTTP requests on mouseovers is the focus of this bug, then OK, it's WFM. OTOH, if the focus of the bug is "very slow, cpu-hogging mouseover of javascript buttons", then I do not see how it's WFM. Compare Mozilla with either IE or NN when moving the mouse over the links on the left side of the page. Mozilla is considerably slower than either one of them.

Hrmm. On My 650 MHz Athlon running Linux and latest nightlies, the mouseover effect tracks mouse movement very closely. It isn't quite as snappy as NN 4.75, but it is still very good. Even the Windows nightly running in a VMware virtual machine performs acceptable. Can you tell us the details of your system, and describe the performance problems? I agree that the performance is not as good as IE (in a VM) or NN, but right now I think the focus is on problems which actually cause noticeably poor performance, like 10-minute table layout runs. If the mouseover speed is fast enough, I suspect that it will be left alone for the time being.

Ok. I'm probably being over-picky here. Yes, it is acceptable. The fact that it's not nearly as good as Netscape bothered me though. Best to stick with the more important bugs, eh?

This is re-fux0red on Linux 2000-11-09-08 Trunk and 2000-11-09-09 MN6. To reproduce: 1) load http://xml.apache.org/ 2) Hit the reload button 3) Move the mouse around on the left-hand navigation bar. Result: an If-Modified-Since request is generated for each event handler, and some images change from being present, to being not found and represented by their ALT text. Expected result: images loaded from image cache. This is a serious regression. Can't ship with a browser that hammers innocent sites.

*** Bug 57860 has been marked as a duplicate of this bug. ***

*** Bug 57667 has been marked as a duplicate of this bug. ***

From a bit of hunting with jprof, the problem with http://soros.ath.cx/ appears to be the n**2 behavior of nsPresContext::StartLoadImage() doing a linear search checking to see if a loader for a given image exists.

It should be useful to clear this bug report of any reference to "...soros.ath..." page. Gosh... pathological indeed. And use of arrays and some loops must have sounded too easy for Robert. This page adds confusion to the problem(s) involved.

nsPresContext::StartLoadImage() isn't the culprit for the soros case, though it is code that should be fixed up.

I take that back - StartLoadImage() is a major problem. I'm working on it - soros is loading about three times faster now with my tree.

*** Bug 64388 has been marked as a duplicate of this bug. ***

soros problem and patch in bug 64438.

*** Bug 66208 has been marked as a duplicate of this bug. ***

Quick comment: problems seen with bug #66208 seem to indicate a recent regression. I just installed Mozilla 0.7 (MacOS 9.0.4) and didn't encounter the problems seen is #66208. Those problems *do* occur in the most recent nightly for Mozilla (01/25/2001). Just lettin' folks know ...

Looks like I may have submitted too soon. My last post wasn't entirely WRONG, but it was only partially correct. Here's some more detail: Bug #66208 reports that rollovers at the following URLs don't behave correctly: https://www.projkts.net/mozilla_bugs/keys_top/imageready.html https://www.projkts.net/mozilla_bugs/keys_top/dreamweaver.html 2 URLs are given to show two different approaches to preloading the images via JavaScript, for completeness sake - I don't believe the JS actually has any bearing on the problem. Both exhibit the same behavior, though. Both these URLs exhibit the same behavior in Mozilla 0.7 and the latest nightly - so that part of my previous post was wrong. However, the following URL: http://www.webprojkt.com/home.html uses the same JS & image structure as the URLs given above (now you see the entire page), however, Mozilla 0.7 is able to roll-over properly as long as you don't reload the current page ... clicking on a link and going to another page that uses the same JS & image structure does NOT break this behavior ... things still work. The only thing that does NOT work in Mozilla 0.7 is reloading the page ... this breaks the rollover behavior by not using the cached images. The same can be said of the nightly build (I just checked). Hope this clarification helps some. A thought: would accessing the page via an SSL URL make a difference to the caching of images? Should it?

I could see SSL causing some images not to be cached. I have no idea if that's involved - seems unlikely.

First of all, Yabadabadoo, I found the problem. Took my protocol analyzer to trace HTTP traffic to and from the server, forget that issue! It's an event problem. Now's the question, do you want the short or the long and detailed report?

Oops here it is, sorry but this is the worng bug, very wrong! How did I do that?

Setting default QA for the currently-assigned component (DOM Level 0)-

All pnunn bugs reassigned to Pav, who is taking over the imglib.

I think this has gotten a lot better with the new imagelib and cache. On yesterday's Linux debug build I am able to mouse over soros.ath.cx page with almost reasonable speed - optimized build might make the experience so good you wouldn't notice any problems. Please retest with a recent build.

I'm not sure if the performance issues have been resolved, but I know cache issues have not. Tested on www.winehq.com and xml.apache.org, the mouseover images are still loaded off the network *for each rollover, each time.* On xml.apache.org, I can easily generate 50k of traffic (according to GKrellM) by just rolling rapidly up and down the sidebar. Maybe we should change the summary? Or should I open a new bug?

cc: self

Hmmmm. Disregard that last one. On Linux 2001040414, caching seems to be working nicely. Thanks, guys!

based on the comments above I am marking this one as fixed. Good job imagelib and cache guys :)

Verified Linux 2001062021.