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

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[Andreas Morawietz]

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

Comment 1

[Andreas Morawietz]

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...

Comment 2

[Andreas Morawietz]

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

Comment 3

[Andreas Morawietz]

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

Comment 4

[Eddie]

(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

Comment 5

[ourasi]

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

Comment 6

[Andreas Morawietz]

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 !!

Comment 8

[w4zsvryct5gx7nf]

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

Comment 9

[Mark Banner (:standard8)]

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.

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

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

Comment 11

[Markus Stange [:mstange]]

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

Comment 13

[Robert Strong (they/them - no direct email)]

It appears that setting hidden on the progressmeter also works

Comment 14

[Robert Strong (they/them - no direct email)]

Attachment: patch - not fully tested

Comment 15

[Robert Strong (they/them - no direct email)]

Attachment: patch rev1

Comment 16

[Dave Townsend [:mossop]]

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?

Comment 17

[Robert Strong (they/them - no direct email)]

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.

Comment 18

[Robert Strong (they/them - no direct email)]

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

Comment 19

[Robert Strong (they/them - no direct email)]

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 20

[Robert Strong (they/them - no direct email)]

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 21

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 367735 [details] [diff] [review]
patch rev1

a191=beltzner

Comment 22

[Robert Strong (they/them - no direct email)]

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

Comment 23

[Tony Chung [:tchung]]

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.