788987 - Persisting CPU-load when clicking repeatedly on tab-bar's scroll buttons.

Status: RESOLVED WORKSFORME

(Firefox :: Tabbed Browser, defect)

Description

[chrcnt7]

When using the scroll buttons of the tab bar to browse through it by clicking multiple times in rapid succession, Fx begins to hog the processor without doing anything.
Using three clicks lets the usage climb faster than double-clicking; spam-clicking lets it consume more the fastest.
This happens even on a new, unmodified profile with tabs just showing about:newtab (opened by spam clicking the new-tab button).

Reproducible: Always

Steps to reproduce:
1. Make sure many tabs are open, 89 were sufficient for me (didn’t try less), but having more seems to accelerate the process. (A freshly reloaded session works, too, they needn’t be freshly opened)
2. Click rapidly on the arrows in the tab-bar until reaching the end in either direction, then repeat it in the other one.
3. Do the clicking a few times to get a measurable increases.
4. To be sure it’s not just temporary load, wait a few minutes, the CPU-usage should persist.

#Important note#
This bug can_not_ be triggered by using the mouse wheel or single clicks (admittedly not tested the whole way through)

Actual result:
Firefox starts to consume CPU power indefinitely in one thread which has the start address firefox.exe+0x1b85*^ (should be the main one), the amount varies by how often the buttons are clicked, but it can go as far as blocking one core completely (represented by 50% CPU-load caused by this thread).
Typically, it ends up with around 25% CPU-load in average for the whole process.
*given by ProcessExplorer (PE)
^if I suspend it (using PE), Fx stops redrawing its windows (they get all white if forced to front)

Expected result:
Near to zero CPU-consumption after enough time to let the GC finish its work.

Additional notes:
-Restarting Fx works as expected and the load is near to zero again afterwards.
-User agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20100101 Firefox/15.0
-Tested it on three different profiles, my main profile, where I loaded a session on startup using Session Manager 0.7.9, my second one, using the built-in facility to restore the last session and a completely new one freshly created for the one and only purpose of investigating what causes this bug. I made sure for both already used profiles that the session I loaded there started with a tab showing just about:blank (disabled the about:newtab-feature using about:config); browser.sessionstore.restore_on_demand is also set to true on both.
-Hardware info: Notebook, CPU: Intel T4200 (dual core, 2 GHz per core), graphics: Nvidia GeForce G 105M, 4GB of RAM
-This problem probably dates back to version 6 or even earlier (5 or 4, but, most likely it didn’t occur in 3.5), at least I have CPU-hogging problemes since back then (but always attributed them to the GC or Flash Player and junk building up while browsing)
-I remember some versions (though unfortunately I can’t tell which) being exceptionally bad and some being that good that I thought the problem had been fixed, but looking back, I probably just happened not to browse through the tab bar by using the buttons in some versions and often in others.

Comment 1

[Jesper Hansen]

This is by design. Here's how the clicking on the scroll buttons work in the tabs:
1 click: moves one tab left or right
2 clicks: moves the entire tab "group". Kinda like you do page down and page up.
3 clicks: moves the tabs listing completely to the left or the right.

Once you know this then it's easier to live with and actually comes useful.

Comment 2

[chrcnt7]

I already know that ;)
Could you please re-read my report?
To be honest, I think you didn’t even understand what it is about, but at least your response came damn fast ;)

Comment 3

[Jesper Hansen]

okay. Thought you were reporting on the jerky behavior when rapidly clicking that triggers the 3 clicks scroll.
As for the cpu usage from rapidly continuous clicking am I unable to replicate

Comment 4

[chrcnt7]

Thought so – it would certainly have been noticed by now if it were widespread behaviour.

Comment 5

[chrcnt7]

Addition (I couldn’t find any edit button):
Switching to private mode stops the excess consumption until going back, when it will reappear. (About as strong as before, but this could be pure chance)
I also let the instance with the fresh profile running untouched while doing other stuff, but the load didn’t drop noticeably even after consuming 3h of total CPU time (not wall-clock time; it has already run for over 25*10^12 cycles!) (but only 7min spent in kernel mode).
The memory consumption doesn’t change much either, nor is it really special (working set: 189MiB (130MiB private), virtual size: 521MiB, private bytes: 153MiB)

Comment 6

[chrcnt7]

I am still reproducing it unintentionally with 16.0.2 (and did so with 16.0.1).
Despite that, I wasn’t able to get it to show up on another system I had access to, which was running XP on a dual-core Intel Pentium with 3.0GHz and 1GiB of Ram, also using 16.0.2.
I noticed that switching to private mode doesn’t make it drop the cpu-usage down to zero again anymore, but instead only to about 15% (even after waiting some minutes to let GC finish for sure).

Comment 7

[chrcnt7]

82 days, nearly three months, and still counting :P …
Is there really nobody out there able to reproduce this bug?
Should I do something special to help you?

By the way, it’s still not gone with 17.0 (just updated).
(Tested with 98 tabs opened by the integrated feature for restoring the last session; they had been freshly opened when I saved it; I clicked my way about ten times back and forth, resulting in about 20% persisting load on/to (?) the cpu (stayed for half an hour, then I closed this instance of Fx)

Comment 8

[chrcnt7]

I updated to 17.0.1 yesterday, rechecked, and … nothing changed.
(I used the seperate profile I used before, with 114 tabs showing about:newtab (but not loaded anyways) and no addons (as far as I remember)). I waited about two and a half hours before I closed it, so I’m pretty sure the load still won’t go away.

Comment 9

[chrcnt7]

Still reproducible using version 18.0.
(Mozilla/5.0 (Windows NT 6.0; rv:18.0) Gecko/20100101 Firefox/18.0)
See the paste for the contents of about:support and about:buildconfig of the Fx-instance running the profile I created for testing: http://codepad.org/LcUyf4F5

Let me know if you need additional information.
By the way, should I update the Version-field of this entry to the most recent version I tested with, or should I reset it to the first version I can think of which suffered from this bug?

Comment 10

[chrcnt7]

I don’t know whether you did something to fix specifically this bug or if it disappeared as a side-effect of another fix, but at least I’m neither able to reproduce it anymore nor triggering it by accident.
I will come back if it appears again. ;)

Thanks for your work. :)