Closed Bug 133217 Opened 18 years ago Closed 18 years ago

[regression] Delay in onmouseover is back


(Core :: Layout: Images, Video, and HTML Frames, defect, major)

Windows 2000
Not set





(Reporter: markushuebner, Assigned: pavlov)




(4 keywords, Whiteboard: [adt2 RTM],custrtm- [ETA 06/27])


(2 files)

The bug 108161 is back - example to test, left menu-items:
with build 2002032203 on win-xp,1.1ghz,327ram
when moving over the menu-items on the left the old behaviour (delay) is back.
The page works fine in 0.9.9
How about cc'ing the crucial people (reviewers, etc.) from bug 108161, eh?  An
empty cc: list is no good.

Further investigations showed that the regression started in build 2002030803.
The build 2002030703 is fine.
WFM: Using 2002032603 build on WinNT running on 433Mhz Intel. Performance on
mouse over is good.
embed triage: topembed-
Keywords: topembedtopembed-
using build 2002032603 on win-xp,1.1ghz,327ram the considerable delay is still 
there at !
worksforme with 032708 mozilla build on win2K. As fast as IE6 for me.
Using build 2002032708 on win2k, amd athlon, 256ram there is a considerable 
delay! Another URL would be the menu-items on the left 
(fernsehen, hörfunk, ...).

I also see moz slower than IE, but not critical, ~20%.

moz 2002032603, duron 950
Keywords: nsbeta1nsbeta1-
It seems that the problem on is due to bug 86319.
But I don't have a clue what is causing the dealy on
Blocks: 92722
I see a problem with and the Main Menu Entrys.
(not the Menu Entrys in the sub Menu)

Mozilla requests the image every time if you move the mouse over an entry and
don't use the cached image. 
My Cache-Setting: Automatic.

I nominate it again, this sucks for all people with a slow connection.
No longer blocks: 92722
nsbeta1+ [adt2 RTM] because I think we REALLY need to fix this for RTM. It isn't
offically blocking any embeddors so topembed-, for now at least, but again, we
really want it, so marked embed.
Whiteboard: [adt2 RTM]
There might be something affecting this in bug 138791.
Component: ImageLib → Image: Layout
Because of comment 11 - isn't this a dup of bug 93461
It seems that the images are not cached but requested again and again from the
Well I don't mean to spam but I don't see that now.
The only thing that changed is a problem with my network connection that I
solved 5 minutes ago.
The common thing about both and is
that it took them over 1 minute to load when I had the network problem.
My new thought is that maybe what you see is this:
When mozilla loads the page it tries to load all the images - because of
problems with the connection it loads them ok but never "thinks" that its done
downloading the images, so every mouseover it retries to download the images and
fails again and again...
Now that the sites load smoothly I don't see the problem anymore.
What do you think?
since imagelib uses the context value to compare between images from the same
document, we need to pass in the same prescontext pointer as we do in layout
Comment on attachment 81566 [details] [diff] [review]
Use the correct prescontext from the html code

Attachment #81566 - Flags: review+
Target Milestone: --- → mozilla1.0
Comment on attachment 81566 [details] [diff] [review]
Use the correct prescontext from the html code
Attachment #81566 - Flags: superreview+
even with this patch, mouseovers do seem a *tiny* bit slower (it may just be my
mind).  on the plus side, this patch will fix a fair number of the bugs related
to images getting fetched from the server twice.
Blocks: 93461
ok, this patch ends up only being a cleanup and doesn't effect anything since 
QI of a nsIPresContext to nsISupports doesn't change anything since
No longer blocks: 93461
Ok, this bug has nothing to do with the previous bug.  Images are *not* being 
reloaded from the network more than once.  I see no regression between 0.9.9 
and the trunk.
Closed: 18 years ago
Resolution: --- → WORKSFORME
Reopening. The bug description doesn't say anything about images being 
reloaded from the network more than once. Testing trunk build 2002042 (win-
xp,1.1ghz,512ram) on for example, the noticeable delay 
is still there. As mentioned this worked perfectly in 0.9.9

Resolution: WORKSFORME → ---
Using build 2002042908 on win2k I also see this annoying delay.
Although all pictures are loaded I get "Transferring data from ..."  It's probably that what is causing the delay.
Could this be related to bug 102321 ?
Do you have a gforce II card...
If you do.. try 1.) Updating the gforce drivers.
                2.) turning off the optimization for the drivers.

Its seems from all the reports.. that some gforce cards are having a hard time
with the bit blits..
Comment on attachment 81566 [details] [diff] [review]
Use the correct prescontext from the html code

Approval noted in bug for branch checking; please make sure it's in the trunk
as well
Attachment #81566 - Flags: approval+
Using trunk build 2002050104 nothing changed.
The delay is there - testing workstations with 4 different video cards.

this may be related to
when that gets checked in..  I bet this goes away, or at least part of the 
Yeah - this one got fixed. using 2002050208 :))
Nice work dcone & saari!
Closed: 18 years ago18 years ago
Resolution: --- → FIXED
Whiteboard: [adt2 RTM] → [adt2 RTM],custrtm-
Verified fixed win 2k build 2002052809
Keywords: adt1.0.1
Blocks: 143047
Keywords: mozilla1.0mozilla1.0.1
Whiteboard: [adt2 RTM],custrtm- → [adt2 RTM],custrtm- [ETA 06/27]
adding adt1.0.1-.  Let's get this in the next release.
Keywords: adt1.0.1adt1.0.1-
Product: Core → Core Graveyard
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.