User-Agent: Opera/9.00 (Windows NT 5.1; U; en) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060615 BonEcho/2.0a3 ID:2006061503 process firefox.exe uses 30% cpu after checking for updates? I just checked for updates and no updates were found. Seems to be ok, but I left that update-window open. I looked in taskmanager while update-window was open: at least 30% cpu usage of process firefox.exe ! Sometimes it is up to 80% I closed that update-window and cpu usage went back to under 1% There must be something wrong with that window after checking for updates. I can reproduce it everytime. Happens also in safe-mode. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060615 BonEcho/2.0a3 ID:2006061503 Console² 0.3.5 DOM Inspector 1.8.1a3 [DISABLED] Flashblock 1.3.4 Image Zoom 0.2.6 JavaScript Options 1.2.4 [DISABLED] Nightly Tester Tools 1.0.4 Popup Count 0.3.4 Talkback 2.0a3 Update Channel Selector 1.0.1 Reproducible: Always

Seems to be fixed in any newer build. Now I use Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060630 BonEcho/2.0a3 ID:2006063018 and all is fine. I wait some days to be absolute sure and then I'll mark this bug as WFM...

still not fixed! using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060808 BonEcho/2.0b1 ID:2006080803

I forgot to say, I have a AMD Duron 1000 CPU. 256 MB RAM

(In reply to comment #2) > still not fixed! > > > using > > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060808 > BonEcho/2.0b1 ID:2006080803 > I confirm same problem here. With the Update window open, Firefox is using between 10% and 15% CPU cycles, closing that window returns to 0. After checking for updates, that windows shouldn't be doing anything, I would think. Using Pentium4 1.7GHz, 1GB PC800 RDRAM, WinXP SP2. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060812 BonEcho/2.0b1 ID:2006081205

Same thing happens with Minefield: When I check for updates and leave that window open, processor stays at 36 - 39 %. After closing I'm back to 1 - 3 %. AMD Duron 900 MHz, 512 MB SDRAM, ATI Radeon 7500, Win XP pro SP2. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060813 Minefield/3.0a1 - Build ID: 2006081302

Problem still there in Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.2pre) Gecko/20070124 BonEcho/2.0.0.2pre ID:2007012403 "After checking for updates, that windows shouldn't be doing anything, I would think." You are right !!

Argh... Andreas please fix the summary spelling so search returns the bug so people don't file dupes.

Confirming with various apps on various platforms. Requesting blocking-firefox3 because this doesn't appear to have been analysed and could be a reproducible symptom of other gecko 1.9 idle CPU usage problems... we are also seeing various problems with CPU in idle mode on Thunderbird (see bug 429929) and the issues between these to bugs may be related. From my tests, the increases in CPU percent (MacBook, 2.4GHz), original % in brackets. FF Mac 20080428 ~10% (from 0%) Linux 2008040704 ~19% (from 0%) TB Mac 2008042903 ~8% (from 8%) Linux 2008040703 ~20% (from 0%) SM Mac 2008042901 ~8% (from 0-2%) Linux 2008042903 ~0% (from 0%) surprising result.

This will not block the final release of Firefox 3. Any patch will need unit tests in order to be approved.

This bug is caused by the undetermined progressbar (see bug 420254 and bug 429929). When the update check is finished, the progressbar animation timer is not canceled and continues to consume CPU. But in contrast to bug 420254 and bug 429929, the progressbar isn't removed, only hidden. It doesn't (can't?) detect this state and keeps animating invisibly. A possible fix would be to remove the progressbar instead of just advancing to the next wizard page, probably somewhere in toolkit/mozapps/update/content/updates.js

It appears that setting hidden on the progressmeter also works

Comment on attachment 367735 [details] [diff] [review] patch rev1 Sounds an awful lot like bug 483367. Do we have a core bug on file to progress bars eating CPU when they aren't visible?

Thought I had seen a core bug but I was likely thinking of bug 483367. I'll file one if I can't find one.

Pushed to mozilla-central http://hg.mozilla.org/mozilla-central/rev/773a6847b6da

mdew, could you verify this is fixed on trunk with tomorrow's nightly? Thanks http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Comment on attachment 367735 [details] [diff] [review] patch rev1 Drivers, this has been on trunk for awhile now and is rather safe as patches go. Besides the constant CPU usage Fennec may also be affected by this to a greater extent.

Comment on attachment 367735 [details] [diff] [review] patch rev1 a191=beltzner

Pushed to mozilla-1.9.1 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/25e053fc15b3

Reporter, can you please verify this on the latest 1.9.1 branch or Trunk nightly? I cannot reproduce this on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4, but doesnt mean my environment could reproduce in the first place.