Over CPU usage when holding down mouse button

VERIFIED FIXED in mozilla1.0



DOM: Events
17 years ago
16 years ago


(Reporter: Nathan Crouse, Assigned: Steve Dagley)



Mac OS X

Firefox Tracking Flags

(Not tracked)



(1 attachment)



17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.7) Gecko/20011221
BuildID:    2001122106

I'm not sure this would be considered a bug, but it might want to be looked
into. I have noticed that when you hold down the mouse button the cpu usage of
mozilla goes as high as it can. The only times this does not occur is if the
click and holding is on a menu or window border. On my machine this is usually
around 80% depending on what other applications I have running. This occurs when
mozilla is not the front application as well. The work around is to not hold
down the mouse button, but if other applications require the mouse to be held
down and dragged then mozilla is taking all the cpu.

Reproducible: Always
Steps to Reproduce:
1. Press and hold the mouse button at any time excpet on a menu or window border

Actual Results:  CPU usage goes to 100%

Expected Results:  I would epect the cpu usage to go up for a moment and then drop

Comment 1

16 years ago
Confirming and reassigning, though CPU usage seems to leap if you hold the mouse
down in other apps (e.g. AIM on OS X). I'm not too familiar with Mac events, but
perhaps the OS X is spamming the app while the mouse is held down. Maybe there
is a way to avoid that behaviour.
Assignee: adamlock → joki
Component: Embedding: APIs → DOM Events
Ever confirmed: true
QA Contact: mdunn → vladimire

Comment 2

16 years ago
-> Dagley, sorry I don't have time to investigate this. See if it is something
that needs to be addressed for the next release
Assignee: joki → sdagley

Comment 3

16 years ago
Hogging cpu while mouse down is part of us not being a good Carbon Event Model 
citizen which is being addressed -> pinkerton (and I think this bug may be a dupe 
of an older bug).

As to us hogging the cpu when the mouse is down in another app - the usage does 
drop back down when the mouse is released (keep in mind Process Viewer defaults 
to samples at 20 second intervals)
Assignee: sdagley → pinkerton

Comment 4

16 years ago
*** Bug 125105 has been marked as a duplicate of this bug. ***
carbonevents -> dagley
Assignee: pinkerton → sdagley

Comment 6

16 years ago
Running Sampler shows we're in the guts of the WaitNextEvent internals for most
of the time when the mouse is down in another app.  This would indicate that
this problem won't be solved until we completely transition from the WNE to
CarbonEvent model -> Moz1.1
Target Milestone: --- → mozilla1.1

Comment 7

16 years ago
I would reclassify this as serious, because it makes other applications 
almost unusable. Even in the background with no open windows, Mozilla 
robs other applications of CPU time whenever the mouse is down, which 
is exactly when you want them to respond quickly.

We must be able to find some kind of workaround that doesn't depend on 
Carbon Events-- do other WaitNextEvent applications have this bug? If it 
can be fixed no other way in time for 1.0, a hack solution would do, such 
as delaying for a tenth of a second (relinquishing the CPU) if we can 
determine that we're being called in the background and the mouse is 

It's easy to underestimate this problem. I wondered why my computer 
seemed so slow for the past few days, and I never would have suspected 
Mozilla, since I wasn't even using it most of the time. But it had been open 
in the background, and some investigation showed it was the culprit. 

To show the problem clearly, use the following command in Terminal:

top -u -s 3

Then hold the mouse button anywhere (such as the Terminal window's 
title bar).Mozilla's CPU usage will go way up, from 3% to to 65%-90% in 
my case.
holy dental hygiene, batman! mozilla does suck down cpu when the mouse is down
and it's in the background. 100% of it!

i hope conrad's newest patch will fix this as it drops the polling behavior we
use now.
Severity: minor → critical
Keywords: nsbeta1, topembed
conrad pointed out the problem is here:


we're checking if the mouse is down, and if it is, we set our sleep time to 0.
obviously, this isn't what we want if we're in the bg. the fix is to check if
the mouse is down && we're in the foreground (via nsToolkit::IsAppInForeground)
before declaring we have an event.

Comment 10

16 years ago
Created attachment 74119 [details] [diff] [review]
Patch to not consier mouse down in other apps a sign it's an event for us

Sneaky, testing btnState directly.  We'd never get to the mouseDown event
handling code since the event wasn't really for us but we'd sure spend a lot of
time trying to.  As pink surmised checking nsToolkit::IsAppInForeground fixes
this behavior.	Now if only I knew what it was conrad was doing since it sounds
like it'd eliminate the need for this specific patch.
Comment on attachment 74119 [details] [diff] [review]
Patch to not consier mouse down in other apps a sign it's an event for us

Attachment #74119 - Flags: review+
to answer dagley's question, no, conrad's patch in bug 105445 will not impact
this. we will still need this patch. (also r=pink)

Comment 13

16 years ago
Comment on attachment 74119 [details] [diff] [review]
Patch to not consier mouse down in other apps a sign it's an event for us

Attachment #74119 - Flags: superreview+


16 years ago
Target Milestone: mozilla1.1 → mozilla1.0


16 years ago
Keywords: nsbeta1, topembed → nsbeta1+, topembed+

Comment 14

16 years ago
Comment on attachment 74119 [details] [diff] [review]
Patch to not consier mouse down in other apps a sign it's an event for us

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #74119 - Flags: approval+

Comment 15

16 years ago
Fix checked in
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 16

16 years ago
Verifying on build 2002-03-26-03-trunk on OSX
*** Bug 141710 has been marked as a duplicate of this bug. ***

Comment 18

16 years ago
this bug appears to be back in RC3 ... clicking and holding down spike the cpu
to 100% on Mac OS X (10.1.4)
You need to log in before you can comment on or make changes to this bug.