227260 - High CPU usage when mouse enters/exits new download/extension/theme managers window area

Status: VERIFIED WORKSFORME

(Toolkit :: Downloads API, defect, P3)

Description

[Radoslaw Sokol]

User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6b) Gecko/20031201 Firebird/0.7+
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6b) Gecko/20031201 Firebird/0.7+

When entering/exiting new Firebird Download Manager's window
with mouse pointer, CPU usage goes up and mouse movement
becomes jerky. One may get CPU usage up to 100% when
just shaking mouse pointer around window's border.

Reproducible: Always

Steps to Reproduce:
1. Open new Download Manager (Downloads) window
2. Move mouse around window's border several times
3. Observe CPU usage

Actual Results:  
CPU usage jumped up to 100%, mouse movement become jerky

Expected Results:  
CPU usage should be minimal

Comment 1

[Jason Barnabe (np)]

I get about 15% CPU usage... But it is higher than other windows like the
Javascript Console. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b)
Gecko/20031130 Firebird/0.7+

Comment 2

[Ali Ebrahim]

I see this too on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b)
Gecko/20031202 Firebird/0.7+.

It doesn't jump to 100%, but it shoots up to around 60% when I move the mouse
around in and out of the DL manager window, where its only about 15% when I move
the mouse around the main Firebird window without the DL manager. I think this
is enough of a performance hit that it's a bug.

Comment 3

[André Langhorst]

new testcase: maximize the window (tested with 1280x1024) and move your mouse in
big rectangles around, not only cpu jumps to 90% but memory usage increases by
4MB (!!!), someone seems to allocate and deallocate a lot of stuff there...

Comment 4

[Ben Goodger (use ben at mozilla dot org for email)]

This seems prevalent at large window sizes. Look at this in 0.9/1.0b

Comment 5

[Joel Frangquist]

I get %55 to %100 when mousing over the download window.

I get %100 when scrolling the download window.

My specs 1.0 GHz, 256 RAM, 16MBvideo(Geforce2Go), XP

Makes the new Download Manager essentially unusable for me, still using a build
with the sidebar version for browsing.  Someone please take this up.

Comment 6

[Jesse Ruderman]

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

Comment 7

[Brian Earley]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

I get no extraordinary CPU usage increases whatsoever when doing this, even when
maximized.

Comment 8

[Daniel Steinberger]

Seems that only some system configurations are affected somehow. On my P4-System
with NVidia Geforce4-gpu everything is reasonable smooth. But on my (faster,
more RAM) Athlon-System with Matrox G450-gpu, the described error occurs. Maybe
this is a driver issue?

Comment 9

[Brian Earley]

Interesting - my computer has a similar config: P4 with nVidia GeForce 4, and it
also works fine for me.

Comment 10

[Bart Ariaans]

I use a p3 646 mhz 192 mb s3 savage 8 mb
cpu rises from 3% to 100% when the download manager opens.

Comment 11

[Ali Ebrahim]

taking qa

Comment 12

[Bart Ariaans]

The problem also occurs on this configuration

P3 730 MHz
256 MB

NVIDIA GeForce2 MX 1000
32 MB

(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8)

Comment 13

[Miachel Santos]

I got a P4 2.4 with a Matrox G550. Using 32bit colourdepth my cpu usage goes up.
Using 24bit colourdepth in WinXP everthings is fine. Maybe this info helps.

Comment 14

[Daniel Steinberger]

from http://mozilla.org/products/firefox/releases/:  Some users have experienced
performance problems with the Downloads window - if the Downloads window
experiences slow painting, try "installing this patch". 
the linked XPI-installer works for me. in case you didn't find it: there is a
fix around. i'm wondering, if it'll be integrated into the next release.

Comment 15

[Ben Goodger (use ben at mozilla dot org for email)]

I'm going to + this in the hope I can find someone to look at it. I may be able
to attach a qfy log. 

Comment 16

[Martijn Wargers (dead)]

The mouse movement becomes especially jerky at my computer when I'm moving the
mouse over the  picture in the download manager.
I have two computers:
With the computer, Duron 800MHz, NVidia Riva TNT2 Model 64 32MB, I see the jerky
mouse movement and high CPU usage.
With the other computer, Duron 600MHz, NVidia Geforce2 MX 100/200 32MB, I don't
see the jerky mouse movement or high CPU usage.

Comment 17

[Martijn Wargers (dead)]

(In reply to comment #16)
> The mouse movement becomes especially jerky at my computer when I'm moving the
> mouse over the  picture in the download manager.
This statement is not true. I see jerky mouse movement in the entire download
manager's window. Sorry for the misinfo (happens when you can't test in on the
other computer directly).

Comment 18

[Dimitrios]

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

Comment 19

[Nickolay_Ponomarev]

This one also affects the new Extension & Theme managers, making them extremely
slow for me (Cel 2GHz + NVidia GeForce MX400).

Comment 20

[Dimitrios]

Modifying summary, according to the (valid) comment #19.

Comment 21

[Mats Åhlberg]

I get the jerky mouse on a Duron 1300 with a matrox millenium g550.

Comment 22

[Bradley Chapman (not reading bugmail, still gone but not forever)]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040609 Firefox/0.8.0+
(daihard: XFT+GTK2; opt. for P4/SSE-2)

Confirmed. The Extension Manager is heavily affected, especially when scrolling
a long list of installed extensions. Additionally, it takes a long time to
select a certain extension and click the preferences/homepage/about buttons, and
resource utilization is heavy during these moments.

Comment 23

[Bradley Chapman (not reading bugmail, still gone but not forever)]

Addendum:

Installing the XPI available on the Fx 0.9 release notes page does not affect
the Extension Manager's performance.

Comment 24

[Fused]

Noticed this on 0.9rc and now 0.9 release in all three download/theme/extension
managers. Doesn't happen with the JS console or bookmarks manager windows.

Moving the mouse over these boxes makes the mouse movement very jerky and CPU
usage around 10-20%.

Here's a good test, it seems if you grab the corner of any of these 3 windows
and resize it back and forth a few times quickly, the CPU almost immediately
pegs at 99% until you stop moving the window and remove mouse cursor focus ...

Comment 25

[jayram]

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

Comment 26

[Georgi]

Can someone confirm that the resolution in bug 246390 works here ?

Comment 27

[Robert Parenton]

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

Comment 28

[Robert Parenton]

From Bug 246390:

>When I open Extenions or Theme Manager and try to scroll it up/down or just move
>my mouse quickly over it, it laggs.

>When I deleted the
>Firefox/chrome/classic.jar/skin/classic/mozapps/shared/viewFader.png

>The lag is no more seen and the Theme/Extension Manager works flowlesly.

Anyone else care to test?

Comment 29

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #28)
>From Bug 246390:
>When I deleted the
>Firefox/chrome/classic.jar/skin/classic/mozapps/shared/viewFader.png
>The lag is no more seen and the Theme/Extension Manager works flowlesly.
> 
> Anyone else care to test?

I've just tested that fix, and it seems to remove the high CPU usage caused by
moving the mouse. I do however still see extremely high cpu usage when resizing
both the extensions and the themes window. Don't know if that should be filed as
a separate bug.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616
Firefox/0.9 (MOOX-AV)

Comment 30

[Bradley Chapman (not reading bugmail, still gone but not forever)]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040619 Firefox/0.9.0+
(daihard: P4/SSE2)

I no longer have slowness when scrolling extensions in the Extension Manager.
CPU utilization is still elevated, but otherwise OK.

Comment 31

[Bradley Chapman (not reading bugmail, still gone but not forever)]

(In reply to comment #30)
> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040619 Firefox/0.9.0+
> (daihard: P4/SSE2)
> 
> I no longer have slowness when scrolling extensions in the Extension Manager.
> CPU utilization is still elevated, but otherwise OK.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040621 Firefox/0.9.0+
(daihard: P4/SSE2)

Spoke too soon. It's back.

Comment 32

[:Gavin Sharp [email: [e-mail]]]

I also may have spoken too soon.

After deleting the viewFader.png file, the CPU usage is not as dramatic as
before, but is still higher than mousing over a regular Firefox window. It goes
to near 40% on a P4 2.5GHz.

Comment 33

[Roasted]

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

Comment 34

[Ben Goodger (use ben at mozilla dot org for email)]

Complex. Unlikely to fix this for 1.0. If a patch appears (run qfy to see what
the problem is... I seem to recall tens of thousands of StretchBlt calls), we
may reconsider if the scope is small. 

Comment 35

[Ben Goodger (use ben at mozilla dot org for email)]

Complex. Unlikely to fix this for 1.0. If a patch appears (run qfy to see what
the problem is... I seem to recall tens of thousands of StretchBlt calls), we
may reconsider if the scope is small. 

Comment 36

[morphis]

For those who suffer from the wacky extension manager, try the patch made by
asqueella: http://user.rol.ru/~nponom/emperfpatch.xpi

It solves the problem for me.

Here is the related discussion topic on mozillazine:
http://forums.mozillazine.org/viewtopic.php?p=625990#625990

Comment 37

[Nickolay_Ponomarev]

I have just filed bug 250050 for inclusion of that extension in release notes
(after reviewing it of course).

Comment 38

[Bradley Chapman (not reading bugmail, still gone but not forever)]

asquella's patch does work, but in its current form it does not address the
slowness of the RDF datasource code - moving extensions around in the manager
still takes a while to execute.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040702 Firefox/0.9.0+
(daihard: P4/SSE2)

Comment 39

[Bart Ariaans]

A strange thing is that the cpu of my computer rises to 100% when I am
downloading a file without entering the mouse in the download manager. Even
without the download manager the cpu rises to 100% when I am downloading a file.
When I am resizing the extension or download manager the cpu "only" rises to
30-35%. Is it possible this are two different problems?

Comment 40

[Bart Ariaans]

Oh and sorry I use:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2

p3 646 mhz (mobile) 192 mb  s3 savage/IX 8mb

Comment 41

[Robert Parenton]

Don't change blocking flags that Ben has already set.

Comment 42

[Alex W]

If you enable the cursor shadow in Windows 2000/XP, or use a cursor with alpha
transparency, the cursor becomes jerky when moving through the
Download/Extension manager. The jerkiness goes away when you use the default
cursor with shadows turned off. Slow scrolling isn’t affected. Themes that do
not use the transparent-fader styling in these windows are not affected.

Comment 43

[Dimitrios]

(In reply to comment #42)
> The jerkiness goes away when you use the default cursor with shadows turned off. 

Not for me on Win2K. There is always jerkiness regardless of the cursor shadow
enable/disable status (setting via Control Panel - Mouse - Pointers). My
graphics card is a Geforce MX 440.

Comment 44

[Mathieu Pellerin]

Bug 255824 , that's the only solution acceptable for now until all the bugs
related to transparent and fixed backgrounds are cleaned by the team, you should
propably go put your vote on this one

Comment 45

[Mark Janssen]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040901
Firefox/1.0 PR (NOT FINAL)

I also get high CPU usage when resizing the extension manager fast and it takes
a second or so before everything is restored.
AMD 2000+, 512mb RAM, nVidia GeForce 4200+, using official nVidia drivers v61.77

Comment 46

[Robert O'Callahan (:roc) (email my personal email if necessary)]

mwarhead, DO NOT change flags that you are not allowed to change.

Comment 47

[Christopher Buman]

I have also experienced high cpu usage in Downloads and Extentions in FFox
1.0pr.  Will this issue be addressed in 1.0 official release?

Comment 48

[Dimitrios]

As far I see, it has been already addressed. I don't see the problem reported in
comment 43 anymore, same hardware/os. The fix for bug 255812 along with the
removal of the background "logo" have totally elliminated the problem for me.
Christopher, you may try a current nightly build from
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-0.9/. Be sure to
use the default (Winstripe) theme.

Comment 49

[Peter van der Woude [:Peter6]]

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

Comment 50

[Andrew Pattison]

StretchBlt will be slow on some graphics cards and fast on others, depending on
whether this particular function is accelerated (i.e. handled by the graphics
card) or, failing that, handled by GDI.

As far as the mouse pointer comments go, most graphics cards nowadays include
mouse pointer acceleration where they draw the cursor over the rest of the
display. This is generally much faster than GDI can do it in software.
Unfortunately this is not possible  with shadowed cursors since the shadow is
transparent so cannot normally be done in hardware. The need to have the shadow
transparent also increases the CPU usage versus drawing an un-shadowed cursor in
software.

Comment 51

[frédéric dénommé]

would just like to confirm this as a serious bug for me (in 1.0 still)..
unlike others i love the download manager interface but
it's really really sluggish and bloated as soon as the mouse gets on it..
here's some screenshots if it makes any difference:
http://evilloop.com/problemo.php
thanks a bunch!

Comment 52

[Mats Åhlberg]

I just tried this on a 450 MHz pentium 3 and i can get it up to 80% of cpu usage.
I had enabled kernel times in the task managar this time and it showed that
95-98 % of the cpu usage was in the Kernel so there is something in the download
manager that sends windows kernel into a tailspin!

Comment 53

[Daniel Steinberger]

Comment #52 suggests that this might be connected to the GPU-driver, as I've
pointed out in comment #8 (I don't encounter that bug on the machine with the
Matrox card under linux). So maybe this is nothing we can really fix but in the
best case find a workaround.

Comment 54

[Worcester12345]

needs aviary landing keyword

Comment 55

[Jez]

Confirm this bug happens on my machine too.

User agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001
Firefox/0.10.1

System: AMD Athlon XP 2800+, 2.09ghz.  512mb ram.  Gfx card = nVidia Geforce3 Ti200.

Comment 56

[Jez]

Update: I've found a way to basically fix this slowdown from occuring on this
system, and I'd be interested to see if doing this helps other systems too.

Right click the desktop, go to Settings, click Advanced, and then there should
be a 'Troubleshoot' tab.  There you can adjust the level of hardware
acceleration.  I just needed to notch mine down one, but push the slider down
until the text says 'Disable cursor and bitmap accelerations.'  OK out of the
dialogs, and try the FF extensions/downloads/etc windows again.

Now they're not causing insane CPU usage.  Definitely seems to be some problem
with cursor/bitmap acceleration causing this.

Comment 57

[Worcester12345]

(In reply to comment #54)
> needs aviary landing keyword

Also needs new milestone, since the original one was missed.

Comment 58

[Mike Connor [:mconnor]]

this has nothing to do with aviary-landing, and isn't going to block 1.1 either.

Comment 59

[Phil Ringnalda (:philor)]

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

Comment 60

[pd]

This bug should be addressed and not dismissed. 

At the very least an xpi should be written to provide easy access to the type of
'solutions' offered in the comments here.

Comment 61

[Worcester12345]

(In reply to comment #58)
> this has nothing to do with aviary-landing, and isn't going to block 1.1 either.

Wow, pretty bold to want to keep a bug which causes such CPU overusage! 

Comment 62

[Jay Patel [:jay]]

Cc'ing Asa to see if we can get the various workarounds/fixes into 1.0.1
documentation. 

Asa: This looks like a good candidate for the release notes. I'm guessing the
solution mentioned in comment #56 is the best option for most users affected.

Comment 63

[Martijn Wargers (dead)]

It might be worth knowing that this might have something to do with bug 244555
and bug 244582. In bug 244582 it is mentioned that the fix for bug 205893 caused
a slow-down.

Comment 64

[Martijn Wargers (dead)]

Sorry, comment 63 is bogus. Backing out the fix for bug 205893, doesn't seem to
make the performance issue in this bug any better.

Comment 65

[Martijn Wargers (dead)]

Attachment: Patch

Ok, this patch makes the bug go away for me. What it comes down to is that
removing the -moz-appearance: listbox; rule makes this bug go away.
the other css rules I added is to keep the same border as before (which is what
the -moz-appearance: listbox rule seems to establish).

For people without a tree, but who still want to test this. You can put
something like this in your userChrome.css:
#downloadView, .themePreviewArea, view {
  -moz-appearance: none !important;
  border: 2px solid;
  -moz-border-top-colors: ThreeDShadow ThreeDDarkShadow;
  -moz-border-right-colors: ThreeDHighlight ThreeDLightShadow;
  -moz-border-bottom-colors: ThreeDHighlight ThreeDLightShadow;
  -moz-border-left-colors: ThreeDShadow ThreeDDarkShadow;
  background-color: -moz-Field;
  color: -moz-FieldText;
  -moz-user-focus: normal;}

I'm using Duron 800MHz, NVidia Riva TNT2 Model 64 32MB 16bit color depth.

Comment 66

[Worcester12345]

Re-request of blocking status, since there is now a patch, so no reason not to
fix for 1.1. Thanks.

Comment 67

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Martijn, do you want to request reviews for this?

Comment 68

[Peter van der Woude [:Peter6]]

(In reply to comment #65)
> For people without a tree, but who still want to test this. You can put
> something like this in your userChrome.css:
> #downloadView, .themePreviewArea, view {
>   -moz-appearance: none !important;
>   border: 2px solid;
>   -moz-border-top-colors: ThreeDShadow ThreeDDarkShadow;
>   -moz-border-right-colors: ThreeDHighlight ThreeDLightShadow;
>   -moz-border-bottom-colors: ThreeDHighlight ThreeDLightShadow;
>   -moz-border-left-colors: ThreeDShadow ThreeDDarkShadow;
>   background-color: -moz-Field;
>   color: -moz-FieldText;
>   -moz-user-focus: normal;}
> 
> I'm using Duron 800MHz, NVidia Riva TNT2 Model 64 32MB 16bit color depth.

That sure helps a lot.
Win2k - Athlon-850MHz  , Geforce G200AGP, 32-bit colordepth

Comment 69

[Mike Connor [:mconnor]]

Comment on attachment 176567 [details] [diff] [review]
Patch

Can someone with a GTK2 build environment post a before and after comparison
here?

I'd rather not just wallpaper over the issue.  If this is cursor-related, what
is the cursor associated with the -moz-appearance: listbox line?

I also don't like the mix of colors, since I'm not sure that those are going to
always coexist well enough.

Comment 70

[Jez]

(In reply to comment #65)
> Created an attachment (id=176567) [edit]
> Patch
> 
> Ok, this patch makes the bug go away for me. What it comes down to is that
> removing the -moz-appearance: listbox; rule makes this bug go away.
> the other css rules I added is to keep the same border as before (which is what
> the -moz-appearance: listbox rule seems to establish).

What I have to ask is: why not fix -moz-appearance: listbox; ?

If that's causing problems, just not using it is the bandaid, fixing that
property is the cure...

Comment 71

[Martijn Wargers (dead)]

I don't think the bug manifests itself with Mozilla builds other than Windows.
Also, I don't think this is a cursor-related problem.

Basically, I just copied the code from here:
http://lxr.mozilla.org/seamonkey/source/themes/classic/global/win/listbox.css#48
So I think nothing should change with the patch.

I think this might be related to the Windows/NVidia bugs that were fixed
recently (see bug 244555 for example).
This bug could also be related to bug 285141.

Yes, the real fix should fix the -moz-appearance: listbox; issue, but I'm not
able to do that.

Comment 72

[pd]

I installed 1.0.3 and saw no difference regarding this bug.

Copying the suggested CSS into the userChrome.css file (via the ever helpful
Chromedit extension), then restarting, works for me.

I agree the default theme or the -moz-appearance handling should be fixed.

For the record:

w2ksp4, nVidia Riva TNT2 Model 64, Pentium 4 1.5 Ghz, 256MB RAM.

Comment 73

[Martijn Wargers (dead)]

Attachment: img for testcase

Comment 74

[Martijn Wargers (dead)]

Attachment: Testcase

This is a minimal testcase of what still causes the bug. The img is just the
viewFader.png from the dowload/extension manager.

Maybe -moz-appearance:listbox is causing some kind of reflow when hovering over
the moz-appearanced element? (somewhere the code in nsNativeThemeWin.cpp
responsible for that?)

The patch fixes the high cpu usage when hovering issue. Butnot other ways that
cause a reflow (like clicking on "Retry"/"Open"/"Remove") I still get a high
cpu usage. That seems the more general issue that transparent png's are slow on
certain NVidia cards on windows in Mozilla.

Comment 75

[Mike Connor [:mconnor]]

Comment on attachment 176567 [details] [diff] [review]
Patch

this isn't going to look right at all across themes, it'll look kinda ok on XP
Luna, but otherwise its not so right, and looks mostly out of place.

Comment 76

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050503
Firefox/1.0+ 10:17pdt

-> WFM

 after checkin for Bug 292472

Comment 77

[Steve England [:stevee]]

The regression date for bug 292472 was between 20050328 (fast scrolling) &
20050329 (slow scrolling).

The extension manager scrolls smoothly in the 20050328 build, but jerkly in the
20050329 build.

Comment 78

[Joey van der Bie]

I'm not only having the CPU increase when i'm moving the mouse over the Download
Manager,
but also when im heavely moving the mouse in the Firefox Browser itself.
Only in the browser itself it is less than in the Download Manager.

I also tested this bug in several other programs, like Internet Explorer, 
but there the increase is just 5% or so, not 30% or 50%!

I have two computers and both are heaving this bug :S

I agree that the Download Window should have the priority, but maybe these bugs
are related and can be solved together?

My comp specs are:
Windows2000 SP4
CPU: PentiumIII 450mhz
Memory: 223MB
GPU: Diamont Multimedia ViperII Z200

and:
WindowsXP SP1
CPU:Athlon1800+
Memory: 512mb
GPU: CLUB3D Ati radeon 9500

Comment 79

[Aaron Slunt]

No CPU spiking on my end (and this is a p3 550 mhz >_>)
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050504
Firefox/1.0+

Patch for 292472, as peter has already implied, most likely fixed it.

So...this depends on 292472?

Comment 80

[Mats Åhlberg]

At the bottom of the following page there is a comments list. The discussion
list has a mouseover that changes the border of the comments.

I get exactly the same bahaviur with cpu usage and mouse jerkiness on my
matrox g550 and a fireGL card.

http://maczealots.com/articles/development/

It seems like firefox does some graphic manipulation that just dont seem to
agree with some graphic-drivers.

Comment 81

[Martijn Wargers (dead)]

I still experience the bug with a 2005-05-08 build, so bug 292472 didn't fix
this for me.

Comment 82

[Jason Gallagher]

The Resizing Window CPU issue that is reported in Comments <A
HREF="https://bugzilla.mozilla.org/show_bug.cgi?id=227260#c24">#24</A> & <A
HREF="https://bugzilla.mozilla.org/show_bug.cgi?id=227260#c29">#29</A>seem to be
unrelated to Firefox.  I tested this by grabbing the bottom right corner and
quickly resizing in and out in other non-firefox programs.  All programs in
Windows being quickly resized caused CPU usage to jump to 100%.  I am using an
AMD Athlon 900Mghtz with 384MB RAM and an ATI Radeon 8500 video card on Windows
XP SP2.

Comment 83

[Nickolay_Ponomarev]

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

Comment 84

[Geert Poels]

I remarked a very strange thing today, related to the behaviour described in
this bug.

Surf to this site : http://www.happydays.be/default_nl.asp
Move your mouse top to bottom and back, in the middle of the screen.
Notice the similar jerky movements of the mouse... .
CPU jumps up as well...

Comment 85

[Mike Connor [:mconnor]]

not going to block on this, but if a good patch that doesn't screw with the
appearance of the managers can be had, great.

Comment 86

[Peter van der Woude [:Peter6]]

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

Comment 87

[Aaron Hamid]

I'm going to chime in here.  This has always happened to me (at least as long as I remember using Firefox) on my windows machines.  Most notable is my dual 1.7gig, 784mb ram, Windows 2000 machine.  This makes the downloads dialog essentially useless to me, because performing ANY interaction in it locks up all of Firefox (even other windows, and possibly other Firefox *processes*, but not sure about that)...so I just have to sit and wait.  Mostly what I am doing is "Remove"ing old downloads...I have dozens of these so you can do the math and see how long I have to wait at my screen clicking...clicking...clicking...

This may ultimately be a Windows or graphics driver fault, but seeing as this behavior doesn't occur in any other app, and that Firefox certainly is aimed squarely at the average 'doze user, I think some concession to fix this should be made.  I'm using 1.5.0.1 at the moment, and of course have been keeping up to date, etc. etc.  I'll give one of the patches mentioned a try, although asqueella's is 404.

Comment 88

[Shawn Wilsher :sdwilsh]

anyone still seeing this?

Comment 89

[pd]

No I've not seen this for a long time.

Comment 90

[Shawn Wilsher :sdwilsh]

Nor do I - Closing.

Comment 91

[Stephen Donner [:stephend] Not actively reading bugmail]

Me neither; verified