925789 - Rapidly flashing participant list scrollbar (with associated CPU load cost)

Status: RESOLVED WORKSFORME

(Thunderbird :: Instant Messaging, defect)

Description

[wsha.code]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20130910160258

Steps to reproduce:

After start up of Thunderbird on OS X:
1. Click on "Chat" to open the Chat tab.
2. Log into an IRC account and join a channel.


Actual results:

The scrollbar of the Participants pane on the right constantly pulses into view (on OS X scroll bars are hidden by default and only become visible when scrolling occurs).

With Thunderbird on a separate desktop from Activity Monitor (so not visible or being interacted with at all), Thunderbird CPU settles down to between 0 and 0.3% for me after startup.  After performing the steps above, it stays around 28%.

If I close the Chat tab or focus the mail window but leave Chat connected to the channel, I see CPU usage of 6%.

If I disconnect from all channels but leave the Chat tab focused, the CPU usage drops back to 0 to 0.3%.


Expected results:

I would not think that leaving the Chat tab focused should require so much CPU.  I'd think that CPU usage should be no more than around 6% as it is when Chat is connected but the Chat tab is not focused.  However, I feel that even the 6% usage seems high.

Comment 1

[Wayne Mery (:wsmwk)]

wsha,

Does this still occur in version 31?

Comment 2

[wsha.code]

The behavior in 31 is improved.

Here is what I see:

Scrollbar of participants still pulses when the list is long enough to require a scrollbar.

With Thunderbird on a separate desktop and a channel open, the CPU usage is about 12% in Activity Monitor.

Focusing the mail tab drops the CPU usage to 10%.

Disconnecting from all channels but leaving the Chat tab focused still drops the CPU usage back close to 0.0%.

New behavior that I noticed:

If I grab the divider between the Participants and Previous Conversations panes and move it slightly, the scrollbar stops pulsing and CPU usage drops to less than 0.1%. After this, I can not reproduce the high CPU usage until I restart Thunderbird. Even joining new channels does not cause the problem to recur.

So it seems like the only remaining problem with high CPU usage is related to this scrollbar pulsing. Hopefully the clue about resizing the panes eliminating the problem helps identify the cause.

Comment 3

[aleth [:aleth]]

(In reply to wsha.code from comment #2)
> If I grab the divider between the Participants and Previous Conversations
> panes and move it slightly, the scrollbar stops pulsing and CPU usage drops
> to less than 0.1%. After this, I can not reproduce the high CPU usage until
> I restart Thunderbird. Even joining new channels does not cause the problem
> to recur.

Unfortunately I can't reproduce the problem. Do you have more detailed STR?

You say you can get rid of the problem by moving the divider. Can you also cause it that way? (i.e. if you move the splitter back, does the flashing scrollbar return?) Is there anything special about the width at which it stops (e.g. does it relate to the participant name lengths in any way)?

Comment 4

[wsha.code]

Attachment: Screenshot of Chat tab layout

Comment 5

[wsha.code]

Sorry, I'm not sure what STR stands for.

No, I have not been able to cause the high CPU usage to return by moving the divider back into place. It is always present after starting Thunderbird and opening the first chat window for me. I tried clicking on the divider between the panes without dragging it, but that did not eliminate the high CPU usage. Neither did dragging any of the other dividers between panes. Only the one between Participants and Recent Conversations affected the CPU usage. I tried opening a channel where I was the only participant, so there was no vertical scrollbar in the participants pane, and the CPU usage was still high until I adjusted the divider between the panes.

I have attached a screenshot of what my Chat tab looks like in case my layout is nonstandard.

Comment 6

[Florian Quèze [:florian]]

(In reply to wsha.code from comment #5)
> Sorry, I'm not sure what STR stands for.

It means "Steps to reproduce". Sorry for our jargon.

Comment 7

[wsha.code]

Hmm, for steps to reproduce:

1. Start Thunderbird 31.0 in a new profile on OS X 10.9.4
2. Skip all of the set up actions regarding email
3. Click on the Chat icon on the toolbar ribbon
4. Add an account and join a network
5. Click on the Join Chat icon
6. Join any channel (you can make up a random channel name so that you are the only participant in the channel)

After these steps my CPU usage is around 10% until I grab the divider between Participants and Previous Conversations and drag it at least one pixel. After this the CPU usage drops close to 0.0%. I haven't been able to make the CPU rise back up by joining other channels, resizing the various panes, closing and opening the Chat tab, etc.

Comment 8

[aleth [:aleth]]

This appears to be the same bug as bug 961232. My suspicion at the time was that we were using DOM mutation events somewhere, which I fixed in bug 976579, but that didn't fix the problem.

Can you take a look in the error console and see if there are any errors or warnings, in particular any mentioning "mutation events"?

Comment 9

[wsha.code]

Yes, two warnings do appear.

First, I should clarify my steps to reproduce above. Step 6 was "Join any channel." Joining a channel creates a new entry in the Conversations pane on the left side of the tab but does not select that entry. Selecting that entry is what causes the CPU usage to go up. If you select the "Conversations" entry itself (the parent of all the channel entries), the CPU usage drops back down until you select a channel again.

When I click on a channel entry in the Conversations pane after joining it (so at the same time as the CPU usage goes up), I see two warnings:

Warning: mutating the [[Prototype]] of an object will cause your code to run very slowly; instead create the object with the correct initial [[Prototype]] value using Object.create
Source File: resource://gre/modules/imThemes.jsm
Line: 92

Warning: mutating the [[Prototype]] of an object will cause your code to run very slowly; instead create the object with the correct initial [[Prototype]] value using Object.create
Source File: resource://gre/modules/imContentSink.jsm
Line: 194

Otherwise, I did not see any warnings generated while performing the steps to reproduce or while changing tabs, resizing panes, selecting channels, etc. There was one other warning present in the Error Console when I first opened it immediately after starting Thunderbird, though I assume it is unrelated to the issue at hand:

Warning: mutating the [[Prototype]] of an object will cause your code to run very slowly; instead create the object with the correct initial [[Prototype]] value using Object.create
Source File: resource://gre/components/steelApplication.js
Line: 783

Comment 11

[aleth [:aleth]]

(In reply to wsha.code from comment #9)
> Yes, two warnings do appear.

Thanks, these warnings are not related, see bug 963519.

Comment 12

[aleth [:aleth]]

Could you please tell me the exact size of your TB window and/or the participant list when this happens? I wonder if I could successfully reproduce this if I started TB with the same window size as you.

I'm pretty sure this won't turn out to be a TB-specific bug at this point.

Comment 13

[wsha.code]

Is there a way to have Thunderbird tell you its exact window size? I don't think it matters though. I tried resizing the window a few times before joining a chat (after restarting Thunderbird each time) and I still saw the high CPU usage for the different window sizes.

Comment 14

[aleth [:aleth]]

I've now also seen this a couple of times.

Comment 15

[Wayne Mery (:wsmwk)]

(In reply to aleth [:aleth] from comment #14)
> I've now also seen this a couple of times.

Can you profile it with https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Thunderbird_Performance_Problem_with_G or remote debugger?

Comment 16

[wsha.code]

I tried to do this. Here was the result:

http://people.mozilla.org/~bgirard/cleopatra/?1440473443968#report=a881086420fbd357927f78ca7edbf15d9c404a64

Comment 17

[aleth [:aleth]]

Thanks wsha.code!

I fear this is a bug somewhere deep in gecko land, and without being to reproduce it consistently it's hard to make progress.

wsha.code: Does this happen every time you start TB for you? Or does TB remember the splitter position so once you move it, the problem doesn't reappear even after a restart?

Comment 18

[Wayne Mery (:wsmwk)]

Anyone else in a position to try to reproduce this?

wsha, the reporter no longer uses IRC

(In reply to aleth [:aleth] from comment #17)

Thanks wsha.code!

I fear this is a bug somewhere deep in gecko land, and without being to reproduce it consistently it's hard to make progress

perhaps related to one of these from https://mzl.la/2DUCSNP (the last one being gecko related)

• bug 1526285 Displaying a list of chat participants with >1000 participants takes several seconds
• bug 1535133 gloda indexing chat conversations with many messages is janky
• bug 1575214 Gloda is getting in the way of typing messages, slow because of jank from synchronous GC

Comment 19

[Patrick Cloke [:clokep]]

I don't think bug 1526285 is related since the example screenshot has a simple conversation with no one else in it.

This bug also doesn't talk about it happening only while messages are being sent / received, which means that gloda shouldn't be involved.

Unfortunately I suspect we should close this as WORKSFORME. The given profile has expired, and without someone else able to reproduce, I'm unsure how we're going to fix it. We've also dramatically reworked this UI via the de-XBL work.