Comment 10 for bug 1209095

So in case of this statusbar scrollbar it is defined in mail/base/content/mailWindowOverlay.xul id="statusbar-progresspanel". The progress is updated in mail/base/content/mailWindow.js::updateProgress . From what I could see we DO NOT call this function often (only once at beginning and once at finish of the progressbar. It is an "undetermined" mode progress bar so it spins by itself once started. It seems the internal XUL implementation of the progressmeter widget is not very efficient. The implementation is in mozilla/toolkit/content/widgets/progressmeter.xml <binding id="progressmeter-undetermined">. There seems to be a tight loop calling mozRequestAnimationFrame() without any throttling (if the mozRequestAnimationFrame does not have any).

According to http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/RequestAnimationFrame/Overview.html this is the intended operation and the application (FF/TB) determines how many frames per second it generates.

So I am not sure what we can do here.

Any anybody check if the progressbar in Firefox is also that CPU heavy?