Closed Bug 141710 Opened 22 years ago Closed 18 years ago

Holding down mouse button forces 100% CPU on Macs

Categories

(Core Graveyard :: Widget: Mac, defect)

Product:
Core Graveyard
Component:
Widget: Mac
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: mozilla, Assigned: mark)

References

Details

(Keywords: platform-parity, qawanted, Whiteboard: Please do not comment: See Comment 57) 

SCENARIO:  When reading text-heavy web sites, I'll often click on a bit of text
and drag the mouse down in order to "force" the window to scroll down.  This
"trick" is an alternative to using the scroll bars that I've used for years.

THE PROBLEM:  If you're scrolling in this matter, or for any other reason
depress the mouse button and keep it held down, Mozilla consumes all available
CPU time.  In OSX, I can confirm with "top" that usage goes up to 100%.  Within
a few seconds, the loud fan on my laptop starts up, so some kinda heavy duty
silicon thinking must be going on.

THE IDEAL SOLUTION:  It would be nice if simply holding down the mouse button
didn't consume so much CPU attention.  I've tried doing this in other Cocoa
applications and mouse-button-holding does not strangle the background apps.

ODD NOTE:  The CPU usage does *NOT* go up significantly if the button is held
down over the scrollbar's thumb.

Thanks guys, and congrats on the upcoming 1.0!
Please always include build ID in bug-reports.
This sounds like a duplicate of bug 116774, fixed on March 14th this year.
With trunk build 2002050108 on Win2k I cannot see this thing.
It was a Mac specific bug.

Reporter: In order to reply to bug-mails, use the link near top of mail and
write in form for "Additional Comemnts" on web.
Marking duplicate, but please reopen if you're seeing this in a recent build...

*** This bug has been marked as a duplicate of 116774 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
I'm sorry, my mistake-- I was under the impression that the bug form
automatically filled in the version of MOzilla, etc.

Anyway, this bug does not appear to be resolved as I downloaded Mozilla only a
few days ago.  RC1- (Build # 2002042203)

Here's some additional info:

Computer:  Powerbook G4 667
RAM:  768 MB
OS Version:  10.1.4


Just to be on the safe side, I'm going to d/l & install a new version (May 2)
and see if that fixes it.  IF not, I'll reopen this bug.
Hey guys-- sorry to report that even on build 2002050208 which I downloaded
moments ago, the CPU usage shoots up to 100% just by highlighting text and
holding down the mouse button.  So it looks like 116774 was incorrectly marked
as resolved.

(powerbook g4 titanium, 764 mb, macos x 10.1.4)

I'm reopening this bug as requested.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Waldo, is that a branch or trunk build you're using?  Also, does the cpu go back
down to 0 when you release the mouse button?  Or does Mozilla freeze with 100% cpu?

Also, if you do _not_ hightlight text, do you still see the CPU jump?
Trunk build, (downloaded today from
ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/).

The CPU goes to 100% even if no text is highlighted.  If I open a blank window
and click in the window and hold down, I still get 100% CPU.

When I release the mouse, usage goes back down to previous levels (not zero, but
less than 10%).

Finally--  if I can extend this bug report a bit-- I ALSO get 100% CPU when
holding the mouse down during selection from the OS X menu bar across the top. 
So if I'm holding the mouse down while browsing bookmarks and trying to find or
choose a bookmark, I have the same 100% problem.

Navigating the menus at the top does not weigh down the system in other OS X
applications such as Mail.app, so I think it's the same bug.  However, Mail.app
is cocoa so therein may lie a difference.

No wait-- I take that back.  Quicken 2001, which is Carbon, does not consume
resources when choosing menu items either.  So this is a Mozilla problem.


I just noticed something else-- if I single-click on the Bookmarks menu item
(such as bookmarks) so that the bookmarks menu pops up, we go up to 100% cpu
that way too.  So I don't even need to be holding down the mouse button.

HOWEVER-- if I click and hold (or just double-click) on ANY OTHER menu item
(file, edit, view, etc) the CPU usage comes down to a reasonable 6% or so..

In fact, I can single click on, say, "File" so that the file menu appears... cpu
usage is normal.  Now if I move the pointer to the right, highlighting new menu
titles and watch the cpu usage, it stays at normal levels past Edit, View, Go,
until it hits "Bookmarks" at which point it skyrockets to 100%, then Tools,
Window, Help, Debug, and QA are all at normal levels.

Very weird, but maybe it'll make sense to you guys...
Waldo, thanks for the information!  Assigning to someone who would know what to
do with this...
Assignee: Matti → sdagley
Status: UNCONFIRMED → NEW
Ever confirmed: true
Any relation to bug 134420?

Any other Component this can go in?
*** Bug 183237 has been marked as a duplicate of this bug. ***
Since I don't report into Internet Technologies anymore this bug needs a new
owner -> saari
Assignee: sdagley → saari
Are people still seeing this bug?

FYI, it makes sense that Bookmarks is different, it is built from a XUL template
reading in the users bookmarks. The other menus are not so dynamic in nature.
Still active in 1.2.1 on a 10.2.3 system. No reason to think it isn't the same
with 1.3beta, but I don't have a copy handy.
It still occurs when holding down mouse button on text area / bookmarks.

mach-o trunk build: 2003012007 on osx 10.2.3
*** Bug 176156 has been marked as a duplicate of this bug. ***
*** Bug 192278 has been marked as a duplicate of this bug. ***
There is no such problem in camino 0.7;

Is this bug related to the feature that popup menu appear if mouse button is
pressed for about 1 second?
This appears to only be a problem in Carbon applications.
The Cocoa-based Camino (nee Chimera) does not appear to
have the problem.
Moz 20030313, OSX 10.2.4, PowerBook G3/400.

When I click-hold-drag the mouse in Mozilla, top only shows a 5-10% increase in
CPU usage compared to just sitting and reading normally. Load average goes above
1, but Idle is around 50%.
Depends on: 106692
Keywords: qawanted
I'm still seeing 98% cpu usage with mouse down in 1.4b, 2003050714. OS X 10.2.6,
powerbook g4 667 DVI. 98% cpu usage with mouse down, ~10% otherwise. Is this
only a powerbook g4 issue? Anyways, holding down the mouse button in a navigator
window, anywhere in the window, including the scroll bar, links, images,
selecting text or not, allowing pop-up to come up or not. Does NOT occur if I
click-drag-hold an image, link, or text selection outline, and NOT if I click
and hold in the (aqua) title or menu bar (except Bookmarks menu). Also does not
occur when click-holding on a PDF displayed with the Schubert pdf plugin or on
its scroll bar (aqua widget).

Also occurs in mail reading and composing windows. Makes selecting text
difficult, because mouse-up event is often not processed at the right place and
so the wrong block of text is selected. Happens with USB mouse as well as
built-in trackpad.
Keywords: pp
*** Bug 134420 has been marked as a duplicate of this bug. ***
Component: Browser-General → XP Toolkit/Widgets
*** Bug 216532 has been marked as a duplicate of this bug. ***
Partial work-around is to use "Classic" theme instead of "Modern". That way you
get Aqua system widgets for scroll bars, which don't exhibit this CPU-eating
behaviour. So at least you can drag-scroll without the fan coming on, which was
the most annoying thing for me...

Otherwise, still getting 100% CPU in 1.5rc1, as described above.
*** Bug 221444 has been marked as a duplicate of this bug. ***
I think this bug should have a higher priority. It is a *blocker* for mobile
life! How am I supposed to use Mozilla if the battery of my Powerbook G4 got
drained by it?
Additional information: using 1.5RC2 and still having the prob.
Flags: blocking1.5?
Since 221444 was marked as a duplicate of this, I can say that it (or something
related) occurs in Camino without holding anything down while scrolling on
certain pages (i.e. it occurs with mousewheel scroll as well as click the arrow
or using the keyboard). Since this seems to contradict earlier info on this bug,
I question whether its actually a dupe. Sorry if I'm just missing something.
You are correct, your bug 221444 should not have been marked a dup of this one,
as this one does not affect Camino. Also this bug does not cause pages to
"scroll very slowly" or produce long delays in changing scrolling direction. In
fact, most people probably wouldn't notice this one unless they're running a cpu
meter or wondering why the #@$ their powerbook fan keeps coming on...

It does however affect Firebird, with the exception that the Bookmarks menu is
not affected.

FYI, I can't reproduce your "slow scrolling" problem in Camino, so 221444 is a
"works for me" (for me, on a tibook). But re-open it if you like.
Flags: blocking1.5?
I see 64% CPU on a G4/400, 10.2.8, Moz 1.6a (normal idle is 0.7%) on mouse-down
on a page.  I see no such problem with the menubar.
*** Bug 231437 has been marked as a duplicate of this bug. ***
*** Bug 253725 has been marked as a duplicate of this bug. ***
*** Bug 268580 has been marked as a duplicate of this bug. ***
(In reply to comment #33)
> *** Bug 268580 has been marked as a duplicate of this bug. ***

Sorry about reporting the dupe, but I can add some more info on this bug now. It
still exists in 1.0 :(

But I can also say that this bug is also present in Thunderbird 0.8 and happens
everywhere in the window, with the sole exception of clicking on scrollbars.
I can confirm that this exists on Firefox 1.0 release. CPU immediately spikes to
100% on every mouse click, and continues when button is held down.
*** Bug 272801 has been marked as a duplicate of this bug. ***
Blocks: 100951
I use Mozilla 1.7.5 on Mac OS X 10.3 and I can confirm that Mozilla still use
100%  of CPU during clicking the left(!) mouse button.
*** Bug 293962 has been marked as a duplicate of this bug. ***
*** Bug 295364 has been marked as a duplicate of this bug. ***
*** Bug 295986 has been marked as a duplicate of this bug. ***
> *** Bug 295986 has been marked as a duplicate of this bug. ***

Sorry for the dupe. I guess I didn't search for the right words.

However, as 295986 mentions, I see this bug using a Powerbook G4 with MacOSX
10.4.1 (Tiger) in the latest (as of 5/30/2005) nightly build of Firefox as well
as Thunderbird 1.0.2 (20050317) and the latest stable release of Mozilla Suite
as of 5/30/2005. I do not see this problem in Camino.

It really looks like Mozilla is polling for the mouse release rather than
waiting for the event. 
I guess in the three years that this bug has been "New", I should have learned C
programming and fixed it myself! Not complaining - just curious - has this
fallen through the cracks, been assigned to a non-existent person, or something?
Or is it just too low-priority to fix?

I did learn enough to replace Mozilla/Firefox scrollbars in my favourite themes
with Aqua ones, which don't exhibit the behaviour, so at least I can scroll
pages without making my powerbook fan come on and the battery die. E-mail me for
instructions if you want.
*** Bug 298145 has been marked as a duplicate of this bug. ***
This Bug is still true with Mozilla 1.7.10. I had this on Mac OS X 10.3 and now
on Mac OS X 10.4.2

Everything that has to do with clicking the left(!) mouse button is
affected(bookmark folders, scrolling, simply clicking in Browser etc.) I guess a
lot of bugs with CPU usage under Mac OS X is depending on this bug. Please, this
is really annying and will be a knock out criteria for Mozilla when I get my
PowerBook, as I don´t want to hear the fan all the time during browsing.
if you use the "classic" theme, you won't have quite as much trouble, since the
native widgets it uses (scroll bar etc.) don't do this. you can also copy them
into other themes. it's still a problem though, when you are selecting text, etc.

since this bug is assigned to "saari (gone) <saari@formerly-netscape.com.tld>" i
have a feeling nobody is paying any attention to it (see my post from may) - i
think it's a zombie bug. but i don't know what to do about that.


This happens because we call WaitNextEvent with a sleep time of 0 if the mouse
is down, so that stuff like scrolling is fast. See nsMacMessagePump::GetEvent().
Assignee: saari → joshmoz
Component: XP Toolkit/Widgets → Widget: Mac
QA Contact: imajes-qa → mac
I think it's clear that that's what you're doing, but it is unclear why you are
doing that. 

Why can't you just wait for the release event like all other OS X applications
do? Why is it necessary to poll for the mouse release? 

Is it really that difficult to change?
How often do we need to update on a scroll?  If we could live with a 15fps 'framerate' we could sleep for 
4 ticks, right?  Even 2 ticks would allow the CPU to come back.  I don't much care about scroll speed 
when my page isn't able to be reflowed correctly.  It's great to have when everything else works well, 
but not instead of everything else working well.

I guess my bigger concern is whether there is code which assumes an event queue block and would get 
confused if it didn't.  But if they exist those all need to get fixed for Carbon Event handling anyway.

I sampled this, we're calling QDFlushPortBuffer over and over again when you
hold the mouse button down.

->mark since he's dealt with this stuff lately
Assignee: joshmoz → mark
Er, this is probably because we're calling WaitNextEvent with a sleep time of 0,
and flushing windows is done via a run loop observer. We need to focus on the
cause, not the symptom.
(In reply to comment #50)
> Er, this is probably because we're calling WaitNextEvent with a sleep time of 0,
> and flushing windows is done via a run loop observer. We need to focus on the
> cause, not the symptom.

The bug has been open since 2002, and I think the cause is known now.  Perhaps
it's time to focus on the solution :-)
*** Bug 237129 has been marked as a duplicate of this bug. ***
*** Bug 311532 has been marked as a duplicate of this bug. ***
(In reply to comment #51)
> (In reply to comment #50)
> > Er, this is probably because we're calling WaitNextEvent with a sleep time of 0,
> > and flushing windows is done via a run loop observer. We need to focus on the
> > cause, not the symptom.
> 
> The bug has been open since 2002, and I think the cause is known now.  Perhaps
> it's time to focus on the solution :-)

i can't believe that is the cause, I do the same thing when browsing to scroll and it always made the fan go on, always wondered why! it seems that should be easy to fix. but i don't no computers well enough to understand why its happening. BTW mine didn't go up to 100% just 94%, and the fan took about 1 minute to come on using a PBG4 1.5Ghz. 
(In reply to comment #51)
> The bug has been open since 2002, and I think the cause is known now.  Perhaps
> it's time to focus on the solution :-)

It is seriously getting time to get this fixed. Firefox 1.5 is still suffering from this issue. And I sure am not going to use Firefox on my laptop, burning battery power, if this bug is still in there.
Still there for me.  I am using Firefox 1.5 for Mac OSX, official build.  Mac OSX 10.4.3, PowerBook 1.5Ghz G4, 1GB RAM.

I am going to have to recommend that any Mac users I know stay away from FireFox until this is fixed.  It makes Google Maps virtually unusable, and it chews up battery, and causes lots of heat in laptops.

This does not occur in Camino.
This bug has been confirmed.  Please do not add comments stating that you can reproduce the bug.  It is known about.
Summary: Holding down mouse button forces 100% CPU → Holding down mouse button forces 100% CPU on Macs
This bug got digged:
http://digg.com/technology/Firefox_Bug_Causes_100_CPU_Usage_on_Mac_OS_X

To those looking for a flame fest: go and read bug 106692. We're taking patches.
*** Bug 322757 has been marked as a duplicate of this bug. ***
Depends on: 332579
Still around.


Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060402 Firefox/1.6a1 ID:0000000000
Whiteboard: Please do not comment: See Comment 57
When I was given this bug, I figured it would wait until the Cocoa move was complete (Fox3 timeframe).  I'm glad to say it didn't wait.  This is fixed by bug 332579 on the 1.8 branch and 326273 on the trunk, both of which contain roughly the same implementation.  (Bug 338153 seeks to update the trunk implementation to match the branch one.)
Status: NEW → RESOLVED
Closed: 22 years ago → 18 years ago
Resolution: --- → FIXED
This problem is definitely gone on FF 2.0b1. I tried it on OS X 10.4.7
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.