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
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
Status: UNCONFIRMED → NEW
Component: Embedding: APIs → DOM Events
Ever confirmed: true
QA Contact: mdunn → vladimire
-> 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
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
*** Bug 125105 has been marked as a duplicate of this bug. ***
carbonevents -> dagley
Assignee: pinkerton → sdagley
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
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.
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: 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.
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 r=ccarlen
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 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
Attachment #74119 - Flags: superreview+
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+
Fix checked in
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Verifying on build 2002-03-26-03-trunk on OSX
Status: RESOLVED → VERIFIED
*** Bug 141710 has been marked as a duplicate of this bug. ***
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.