20110 - very slow, cpu-hogging mouseover of javascript buttons

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect, P3)

Description

[Philippe Mondon]

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.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 2

[Sean Richardson]

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"

Comment 3

[Mike McCabe]

Reassigning to DOM component.

Comment 4

[vidur (gone)]

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

Comment 5

[Sean Richardson]

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.

Comment 6

[vidur (gone)]

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?

Comment 7

[Mike Shaver (:shaver emeritus)]

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

Comment 8

[Mike Shaver (:shaver emeritus)]

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

Comment 9

[R.K.Aa.]

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)

Comment 10

[moshev]

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

Comment 11

[Daniel Roberts]

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

Comment 12

[John Dobbins]

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

Comment 13

[Mike Shaver (:shaver emeritus)]

Sweet, sweet news indeed.

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

Comment 14

[R.K.Aa.]

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.

Comment 15

[Chris Waterson]

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

Comment 16

[Mike]

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

Comment 17

[WD]

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

Comment 18

[WD]

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.

Comment 19

[Chris Waterson]

taking from shaver for now

Comment 20

[WD]

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

Comment 21

[Jeffrey Baker]

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 [e-mail], and leave it
up to neeti to reassign to Networking: Cache if I am right.

Comment 22

[R.K.Aa.]

seems bug 47767 is another dup

Comment 23

[Jeffrey Baker]

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

Comment 24

[ekrock's old account (dead)]

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.

Comment 25

[neeti]

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

Comment 26

[pnunn]

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

Comment 27

[neeti]

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

Comment 28

[neeti]

Reassigning to myself.

Comment 29

[rogerl (gone)]

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

Comment 30

[neeti]

--->Pam

Comment 31

[pnunn]

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

Comment 32

[Randell Jesup [:jesup] (needinfo me)]

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

Comment 33

[Jeffrey Baker]

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.

Comment 34

[Mike Shaver (:shaver emeritus)]

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

Comment 35

[pnunn]

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

Comment 36

[Mike Shaver (:shaver emeritus)]

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.)

Comment 37

[pnunn]

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

Comment 38

[pnunn]

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

Comment 39

[neeti]

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.

Comment 40

[Jeffrey Baker]

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.

Comment 41

[Jeffrey Baker]

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.

Comment 42

[Jeffrey Baker]

Attachment: tcpdump output from xml.apache.org rollovers

Comment 43

[pnunn]

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

Comment 44

[neeti]

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

Comment 45

[Jeffrey Baker]

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.

Comment 46

[Jeffrey Baker]

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

Comment 47

[Jeffrey Baker]

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.

Comment 48

[WD]

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?

Comment 49

[Jeffrey Baker]

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?

Comment 50

[WD]

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.

Comment 51

[Jeffrey Baker]

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.

Comment 52

[WD]

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?

Comment 53

[Jeffrey Baker]

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.

Comment 54

[pnunn]

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

Comment 55

[Matthias Versen [:Matti]]

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

Comment 56

[Martin Jacobs]

Attachment: preloaded animated gif IMG doesn't show up (from dupe #57860)

Comment 57

[tor]

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.

Comment 58

[Martin Jacobs]

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.  

Comment 59

[tor]

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

Comment 60

[tor]

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.

Comment 61

[Blake Ross]

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

Comment 62

[tor]

soros problem and patch in bug 64438.

Comment 63

[Brice Ruth]

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

Comment 64

[Brice Ruth]

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 ... 

Comment 65

[Brice Ruth]

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?

Comment 66

[Randell Jesup [:jesup] (needinfo me)]

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

Comment 67

[HJ]

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?

Comment 68

[HJ]

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

Comment 69

[Phil Schwartau]

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

Comment 70

[pnunn]

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

Comment 71

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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.

Comment 72

[Brian Teague]

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?

Comment 73

[Brian Teague]

cc: self

Comment 74

[Brian Teague]

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

Comment 75

[Gagan]

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

Comment 76

[Tom Mraz]

Verified Linux 2001062021.