431573 - Turning off toolbar containing "Folder location" item makes Thunderbird use 100% CPU continuously

Status: RESOLVED FIXED

(Thunderbird :: Toolbars and Tabs, defect)

Description

[Martin Stubenschrott]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008042404 Minefield/3.0pre
Build Identifier: version 3.0a1pre (2008042903)

Whenever I turn off the Toolbar with View->Toolbars->Main Toolbar, CPU instantly goes to 100%, and keeps that value for most of the time. Also scrolling messages is then much slower then. Only verified under Linux, not tested on other OSes.

When I turn the tooblar back on, a strange thing happens:
-) The CPU usage goes back to normal, but
-) I see a menu with items: "People I Know", "Recent Mail", "Last 5 days" on the top left of the thunderbird window, but this menu never disappears again. I need to restart firefox. If a linux-thunderbird3 user can't reproduce that, I will upload a screenshot somewhere.

Reproducible: Always

Steps to Reproduce:
1. turn off the Toolbar with View->Toolbars->Main Toolbar
Actual Results:  
High CPU usage

Expected Results:  
Same CPU Usage as with toolbar visible.

Comment 1

[Martin Stubenschrott]

Ah, I found out, what causes the problem:

1.) The high CPU is only visible when I drag the "Folder location" combo box to the toolbar
2.) The "sticky menu" bug is only visisible when i drag the "View:" item to the toolbar.

So in the default configuration, both problems are not visible, but still they should be fixed.

Comment 2

[Rod Whiteley]

Confirming the CPU problem.  On Windows XP I see one processor fully utilized when the toolbar contains the Folder location and is hidden.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008050103 Thunderbird/3.0a1pre

It is probably best to report the other problem separately.  FWIW, I do not see it on Windows.

Comment 3

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

This looks familiar to me... Something about fully utilized / taking up excessive CPU resources. Might it be related to IMAP issues, however unlikely?

Not exactly an Alpha 1 blocker, but nominating for Alpha 2.

Comment 4

[Wayne Mery (:wsmwk)]

I don't see CPu change in version 3.0a1pre (2008042303) Vista - so is this a regression after (2008042303)?

item 2 is a dupe of a bug (i've seen the screen shot) which irrc doesn't have steps to reproduce. I think it has the words tool tip, pop up or mouse over in the summary.

Comment 5

[Martin Stubenschrott]

(In reply to comment #4)
> I don't see CPu change in version 3.0a1pre (2008042303) Vista - so is this a
> regression after (2008042303)?

No i have seen the first issue for at least two months now, was just too lazy to report :) Maybe it's GTK only however.

Comment 6

[Magnus Melin [:mkmelin]]

Not caused by an extension by any chance? Tried disabling them all? (With default theme.)

Comment 7

[David Ascher (:davida)]

I can repro on OS X, btw.

STR:

 1. customize toolbar, add "Folder location" item
 2. hide toolbar.
 3. watch cpu spike to 100%.

Note that I think the "folder location" isn't the right implementation for the use case it's trying to solve.

I don't think this is a common scenario, so not blocking a2.  It should block tb3, though.

Comment 8

[Bryan Clark (DevTools PM) [:clarkbw]]

Any change in recent builds?  Marking this for rc1 and taking so it's my job to find an owner.

Comment 9

[Wayne Mery (:wsmwk)]

Martin, can you still see this problem?  May be hard to know for certain whether this is gone, with the regression bug 465269 unfixed

Comment 10

[Martin Stubenschrott]

Sorry for the late answer.

Seems to work ok with:

Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1b4pre) Gecko/20090324 Shredder/3.0b3pre and with Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1b5pre) Gecko/20090504 Shredder/3.0b3pre.

However, when i enable that toolbar "icon", it does not populate correctly with entries (as of this TB version), but well that's bug 465269 :) . I think this one can be closed, maybe a reference to it added to 465269, so when 465269 is fixed, this one does not regress.

Comment 11

[Bryan Clark (DevTools PM) [:clarkbw]]

ok, closing this now.  I'm going to make a note in bug 465269 about this as well.