Please report any other irregularities here.
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 At first I thought this might be a dupe of bug 322232, but my stack doesn't have any obvious connection to plugins. Only a few more data points will reveal the truth, I think. I find after a day or three of browsing that an idle firefox will consume 40-60% of my Powerbook G4's CPU. Enough was enough, I said, egged on by shaver, and installed Shark. The results are relatively unambiguous. This is the stack that is responsible for the first 40%: 0.0% 46.8% firefox-bin start 0.0% 46.8% firefox-bin nsAppStartup::Run() 0.0% 46.8% firefox-bin nsAppShell::Run() 0.0% 46.8% firefox-bin nsMacMessagePump::DoMessagePump() 0.0% 46.8% firefox-bin nsMacMessagePump::GetEvent(EventRecord&) 0.0% 46.8% HIToolbox WaitNextEvent 0.0% 46.8% HIToolbox WNEInternal 0.0% 46.7% HIToolbox GetNextEventMatchingMask 0.0% 46.2% HIToolbox RunCurrentEventLoopInMode 0.0% 45.9% CoreFoundation CFRunLoopRunSpecific 0.1% 43.6% CoreFoundation __CFRunLoopRun 0.0% 42.6% CoreFoundation __CFRunLoopDoSources0 0.0% 42.3% libxpcom_core.dylib PL_ProcessPendingEvents 0.0% 42.1% libxpcom_core.dylib PL_HandleEvent 0.0% 42.0% libxpcom_core.dylib handleTimerEvent(TimerEventType*) 0.0% 41.8% libxpcom_core.dylib nsTimerImpl::Fire() 0.0% 41.3% firefox-bin imgContainerGIF::Notify(nsITimer*) 0.1% 41.0% firefox-bin imgContainerGIF::DoComposite(gfxIImageFrame**, nsRect*, gfxIImageFrame*, gfxIImageFrame*, int) 0.0% 39.9% firefox-bin gfxImageFrame::DrawTo(gfxIImageFrame*, int, int, int, int) ... more inner frames ... The other 60% is the kernel doing IPC, handling faults, and adjusting mappings. Related to the non-stop GIF drawing, I assume? I don't know, you tell me. To anticipate a few questions: - No, there are no pages loaded with plugins (or gifs). In fact, no pages visible of any kind. Before I gathered the data, I closed all tabs except for one new empty one, pure as the wind-driven snow. - In three days of heavy use, the browser has probably seen every kind of content imaginable. - I've been suffering with this for months, but I have not yet detected a pattern to any particular type of content that triggers it. - Restarting the browser resets the clock, and I get another day or three until I notice that my fan never turns off anymore. - To make the pain of restarting every three days less acute, I installed SessionSaver. But this behaviour long predates my use of that plugin. One stack trace is not maximally useful, but I'll add more Shark data until it becomes clear that there is a trend, or the bug gets fixed, or Safari gets adblock. I kept the raw data, but each 30-second snapshot is 1.4 MB. If someone wants it, I'll attach it, or put it on the web. I'm sure that someone will figure out in which component this belongs, but maybe only after some analysis. Reproducible: Always Steps to Reproduce:
I've asked Phil to test disabling fastback, to see if that affects the behaviour. (It happens to me, too.)
Status: UNCONFIRMED → NEW
Ever confirmed: true
With fastback disabled (max_total_viewers at 0), this still happened.
*** Bug 327143 has been marked as a duplicate of this bug. ***
Is this still relevant or has code churn made it obsolete?
You need to log in before you can comment on or make changes to this bug.