Closed Bug 341749 Opened 16 years ago Closed 13 years ago

30% cpu usage check for updates while window dialog is up

Categories

(Toolkit :: Application Update, defect)

x86
All
defect
Not set
major

Tracking

()

RESOLVED FIXED
mozilla1.9.1b4

People

(Reporter: mailbox, Assigned: robert.strong.bugs)

References

Details

(Keywords: fixed1.9.1, perf)

Attachments

(1 file, 1 obsolete file)

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
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: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 !!
Duplicate of this bug: 376983
Argh... Andreas please fix the summary spelling so search returns the bug so people don't file dupes.
Summary: 30% cpu useage during check for updates → 30% cpu usage during check for updates
Keywords: perf
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.
Flags: blocking-firefox3?
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.
Flags: wanted-firefox3+
Flags: blocking-firefox3?
Flags: blocking-firefox3-
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
Product: Firefox → Toolkit
Duplicate of this bug: 429504
It appears that setting hidden on the progressmeter also works
Attached patch patch rev1Splinter Review
Assignee: nobody → robert.bugzilla
Attachment #367734 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #367735 - Flags: review?(dtownsend)
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
Flags: wanted1.9.1?
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
Keywords: fixed1.9.1
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.