Closed Bug 341749 Opened 16 years ago Closed 13 years ago
30% cpu usage check for updates while window dialog is up
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: firefox.exe uses 30% cpu after checking for updates → 30% cpu useage during check for updates
Problem still there in Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:22.214.171.124pre) Gecko/20070124 BonEcho/126.96.36.199pre 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.
15 years ago
Summary: 30% cpu useage during check for updates → 30% cpu usage during check for updates
Summary: 30% cpu usage during check for updates → 30% cpu usage check for updates while window dialog is up
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.
OS: Windows XP → All
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
Duplicate of this bug: 429504
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?
Attachment #367735 - Flags: review?(dtownsend) → review+
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
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
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/
Attachment #367735 - Flags: approval1.9.1?
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
Attachment #367735 - Flags: approval1.9.1? → approval1.9.1+
Pushed to mozilla-1.9.1 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/25e053fc15b3
Target Milestone: --- → mozilla1.9.1b4
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.
You need to log in before you can comment on or make changes to this bug.