The default bug view has changed. See this FAQ.

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

VERIFIED WORKSFORME

Status

()

Toolkit
Downloads API
P3
normal
VERIFIED WORKSFORME
14 years ago
6 years ago

People

(Reporter: Radoslaw Sokol, Assigned: roc)

Tracking

({perf, relnote})

unspecified
x86
Windows XP
perf, relnote
Points:
---
Dependency tree / graph
Bug Flags:
blocking-aviary1.5 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

14 years ago
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

14 years ago
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

14 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

14 years ago
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...
This seems prevalent at large window sizes. Look at this in 0.9/1.0b
Assignee: blake → bugs
Priority: -- → P3
Target Milestone: --- → Firebird0.9

Comment 5

13 years ago
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.

Updated

13 years ago
Keywords: perf

Comment 6

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

Comment 7

13 years ago
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

13 years ago
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

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

Comment 10

13 years ago
I use a p3 646 mhz 192 mb s3 savage 8 mb
cpu rises from 3% to 100% when the download manager opens.
Status: NEW → ASSIGNED
Target Milestone: Firefox0.9 → Firefox1.0beta

Comment 11

13 years ago
taking qa
QA Contact: aebrahim

Comment 12

13 years ago
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)

Flags: blocking1.0?

Comment 13

13 years ago
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

13 years ago
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.
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. 
Flags: blocking1.0? → blocking1.0+
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.
(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

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

Comment 19

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

Comment 20

13 years ago
Modifying summary, according to the (valid) comment #19.
Summary: High CPU usage when mouse enters/exits new download manager's window area → High CPU usage when mouse enters/exits new download/extension/theme managers window area

Comment 21

13 years ago
I get the jerky mouse on a Duron 1300 with a matrox millenium g550.
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.
Addendum:

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

Comment 24

13 years ago
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

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

Comment 26

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

Comment 27

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

Comment 28

13 years ago
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?
(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)
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.
(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.
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

13 years ago
*** Bug 247460 has been marked as a duplicate of this bug. ***
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. 
Flags: blocking1.0mac-
Flags: blocking-aviary1.0RC1-
Flags: blocking-aviary1.0-
Flags: blocking-aviary1.0+
Target Milestone: Firefox1.0beta → Firefox1.0
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. 
Assignee: bugs → roc
Status: ASSIGNED → NEW

Comment 36

13 years ago
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

13 years ago
I have just filed bug 250050 for inclusion of that extension in release notes
(after reviewing it of course).
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

13 years ago
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?
Flags: blocking-aviary1.0RC1?
Flags: blocking-aviary1.0RC1-
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0-

Comment 40

13 years ago
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

13 years ago
Don't change blocking flags that Ben has already set.
Flags: blocking-aviary1.0RC1?
Flags: blocking-aviary1.0RC1-
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0-

Comment 42

13 years ago
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

13 years ago
(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

13 years ago
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

13 years ago
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

Updated

13 years ago
Blocks: 262161

Updated

13 years ago
Flags: blocking-aviary1.0- → blocking-aviary1.0+
mwarhead, DO NOT change flags that you are not allowed to change.
Flags: blocking-aviary1.0+ → blocking-aviary1.0-

Updated

13 years ago
No longer blocks: 262161

Comment 47

13 years ago
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

13 years ago
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.
*** Bug 254102 has been marked as a duplicate of this bug. ***

Comment 50

13 years ago
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.
OS: Windows NT → Windows XP

Comment 51

13 years ago
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

13 years ago
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

13 years ago
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

12 years ago
needs aviary landing keyword

Comment 55

12 years ago
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

12 years ago
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

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

Also needs new milestone, since the original one was missed.
Flags: blocking-aviary1.1?
this has nothing to do with aviary-landing, and isn't going to block 1.1 either.
Flags: blocking-aviary1.1? → blocking-aviary1.1-
*** Bug 281924 has been marked as a duplicate of this bug. ***

Comment 60

12 years ago
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

12 years ago
(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

12 years ago
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.
Keywords: relnote
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.
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.
Created attachment 176567 [details] [diff] [review]
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

12 years ago
Re-request of blocking status, since there is now a patch, so no reason not to
fix for 1.1. Thanks.
Flags: blocking-aviary1.1- → blocking-aviary1.1?
Martijn, do you want to request reviews for this?

Updated

12 years ago
Attachment #176567 - Flags: review?(mconnor)
(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 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

12 years ago
(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...
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

12 years ago
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.

Updated

12 years ago
Blocks: 255824
Created attachment 182064 [details]
img for testcase
Created attachment 182069 [details]
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 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.
Attachment #176567 - Flags: review?(mconnor) → review-
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
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

12 years ago
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

12 years ago
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?
Depends on: 292472

Comment 80

12 years ago
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.
I still experience the bug with a 2005-05-08 build, so bug 292472 didn't fix
this for me.

Comment 82

12 years ago
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

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

Comment 84

12 years ago
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...
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.
Flags: blocking-aviary1.1? → blocking-aviary1.1-
*** Bug 297953 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.0mac-
Flags: blocking-aviary1.0PR-
Flags: blocking-aviary1.0-

Comment 87

11 years ago
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.

Updated

10 years ago
QA Contact: ali → download.manager
anyone still seeing this?
Target Milestone: Firefox1.0 → ---

Comment 89

10 years ago
No I've not seen this for a long time.
Nor do I - Closing.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
Me neither; verified
Status: RESOLVED → VERIFIED
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.