116774 - Over CPU usage when holding down mouse button

Status: VERIFIED FIXED

(Core :: DOM: Events, defect)

Description

[Nathan Crouse]

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

[Adam Lock]

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.

Comment 2

[saari (gone)]

-> Dagley, sorry I don't have time to investigate this. See if it is something
that needs to be addressed for the next release

Comment 3

[Steve Dagley]

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)

Comment 4

[R.K.Aa.]

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

Comment 5

[Mike Pinkerton (not reading bugmail)]

carbonevents -> dagley

Comment 6

[Steve Dagley]

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

Comment 7

[Andrew Shearer]

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

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.

Comment 8

[Mike Pinkerton (not reading bugmail)]

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.

Comment 9

[Mike Pinkerton (not reading bugmail)]

conrad pointed out the problem is here:

http://lxr.mozilla.org/mozilla/source/widget/src/mac/nsMacMessagePump.cpp#377

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

[Steve Dagley]

Attachment: 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 11

[Conrad Carlen (not reading bugmail)]

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

r=ccarlen

Comment 12

[Mike Pinkerton (not reading bugmail)]

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

[Simon Fraser [no longer active]]

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

sr=sfraser

Comment 14

[Asa Dotzler [:asa]]

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

Comment 15

[Steve Dagley]

Fix checked in

Comment 16

[Vladimir Ermakov]

Verifying on build 2002-03-26-03-trunk on OSX

Comment 17

[Boris Zbarsky [:bzbarsky]]

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

Comment 18

[paul w brown]

this bug appears to be back in RC3 ... clicking and holding down spike the cpu
to 100% on Mac OS X (10.1.4)