Closed Bug 400120 Opened 17 years ago Closed 10 months ago

Add statically-updated, per-tab CPU and RAM monitor

Categories

(Firefox :: General, enhancement)

enhancement

Tracking

()

RESOLVED INACTIVE
Tracking Status
e10s - ---

People

(Reporter: dterrors, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.3 MEGAUPLOAD 1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.3 MEGAUPLOAD 1.0

I request that you add the ability for users to see how much CPU (and mem) each of their open web browser windows and/or tabs are using.

Often, I will have 20 windows open (and a couple tabs in some), and my cpu will be at 50%, my processor fan spinning up to full blast.  Everything in ffox slows down.  And then I close one particular window and all of a sudden everything is calm and smooth.  I presently have no way to determine which window/tab/page is the hog, besides manually closing every one (and then reopening it if it's not the problem window).  

I have asked some extension developers who tell me this is too low-level for them to do, hence I'm here.



Reproducible: Always

Steps to Reproduce:
this is not applicable
Sites with java, news tickers and flash are using most of the resources.
So everything that moves :).
Adblock Plus can filter them out.
Blocks: 453420
I would like to second this feature request (on all platforms, because I'm on a Mac), as I tend to keep a whole lot of tabs open (75-100+ in one window), and it would be nice to know what is causing Firefox to slow to a crawl so I could eliminate that tab from my workflow.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: x86 → All
Version: unspecified → Trunk
Summary: Please provide the ability to see which open web page tab/window is sucking up the most CPU. → Add CPU and RAM monitor on a per-tab basis
Blocks: 515354
No longer blocks: 515354
Depends on: 515354
I don't have massive amounts of tabs open at any one time, usually around 10 to 15, but this would be a good feature to have, especially when bug #102474, #156493 and #452272 are implemented.
Blocks: 515352
Blocks: 340372
Bug 625305 will partially solve this.  It'll give memory usage per compartment, which roughly means per domain (a single tab can have multiple compartments, and a single compartment can span multiple tabs).  It won't help with the CPU usage, though;  that one seems harder.
(In reply to comment #6)
> Bug 625305 will partially solve this. 

Bug 661474 ended up doing this.
Depends on: 687724
Depends on: 710927
Summary: Add CPU and RAM monitor on a per-tab basis → Add statically-updated, per-tab CPU and RAM monitor
An indication that a tab is using a lot of resources by changing the tab colour would be very nice - in my opinion more useful than a fullblown monitor.  I realise that Firefox pops up a warning window in some extreme cases, but in some less extreme cases the user might want to know but still be able to ignore it if the resource usage is expected.
That would be very nice. :-) Not always on, but togglable on and off.
And how to find the red tab(s) ?
Let's have a arborescence listing all the Firefox windows, with all their tabs and each tab is displayed with its CPU colour. A RAM colour would be interesting too.
The last 2 comments are describing bug 662768
Nicolas: colouring the tab and having a tree of open tabs sound like two things which can be done separately.  I would say that just two colours of tab would be enough - normal and warning.  The user can still spot the coloured ones by scrolling through the list, and that is a lot faster than closing and re-opening each, checking Firefox's resource usage in-between.  The mouse-over hovering/"what's this" text for the tab, which currently only shows the title of the web page, could be extended with one or two additional lines - "Using x% of system memory." and/or "Using x% of system computing power."

Mardeg: thanks for pointing that out.
Mass tracking-e10s flag change. Filter bugmail on "2be0fcce-e36a-4e2c-aa80-0e3d33eb5406".
tracking-e10s: --- → +
would the CPU times have to be tallied separately for the JS engine and each and every plugin (java, flash, etc.)?

without knowing about any internals, i assume there are occasional context changes, each of which could be timed (at a performance penalty, completely acceptable in the case described by several other commenters).
The problem is, I think, frequently caused by dynamic websites which constantly refresh.

Personally, I'd like Firefox to completely "freeze" background tabs giving them zero CPU, stopping all scripts, and after 1 minute of ignoring them, then flush the current state to disk and out of RAM. 

(Of course, there will need to be a very few exceptions, eg Gmail continuing to fetch mail, or a single instance of Youtube playing music, but by and large, background tabs should consume no more resources than a bookmark).

Part of the root cause is that there is no good way in JS for the site to detect when a tab is inactive (note that window->blur is no use on a multi-screen setup).
No doubt all of this is true, but right now we don't even have a way of identifying which tabs are the culprits.

Having a 'freeze' in background capability could be an exceptionally nice feature. Something you can turn on/off for specific sites would make this especially powerful - that way we could configure things to run where it actually made sense, and block updates from those sites where it doesn't.

The other day I was trying to figure out why my PC wasn't going into power-save mode.  There were too many firefox tabs doing useless work, which caused the CPU to be above the threshold at which the system would suspend itself.  So it has been running for days - doing useless work the whole time, and heating up the office on days where it needed no additional heat.
(In reply to Richard Neill from comment #18)
> The problem is, I think, frequently caused by dynamic websites which
> constantly refresh.
> 
> Personally, I'd like Firefox to completely "freeze" background tabs giving
> them zero CPU, stopping all scripts, and after 1 minute of ignoring them,
> then flush the current state to disk and out of RAM. 
The bug for discussing the implementing this is bug 675539.
(In reply to Eric Youngdale from comment #19)

> Having a 'freeze' in background capability could be an exceptionally nice
> feature. Something you can turn on/off for specific sites would make this
> especially powerful - that way we could configure things to run where it
> actually made sense, and block updates from those sites where it doesn't.
> 
> The other day I was trying to figure out why my PC wasn't going into
> power-save mode.  There were too many firefox tabs doing useless work, which
> caused the CPU to be above the threshold at which the system would suspend
> itself.  So it has been running for days - doing useless work the whole
> time, and heating up the office on days where it needed no additional heat.

This freeze feature would be a very good idea in itself. It would also have beneficial side effects : 
 1) Sometimes, I leave Firefox open, and when I come back at work the next morning I find that Firefox has crashed alone during the night. With a bit of luck, the freeze feature would avoid that. 
 2) Firefox horribly auto-reloads some pages, this disturbs the user and often this makes the user lose the content s/he has entered. Firefox does this even when the pref is set to the contrary. This is a long-known bug of Firefox. The freeze feature would stop that.

(In reply to Mardeg from comment #20)

> > The problem is, I think, frequently caused by dynamic websites which
> > constantly refresh.
> > 
> > Personally, I'd like Firefox to completely "freeze" background tabs giving
> > them zero CPU, stopping all scripts, and after 1 minute of ignoring them,
> > then flush the current state to disk and out of RAM. 

> The bug for discussing the implementing this is bug 675539.

Not exactly. 

By *freezing*, what I want is just freezing : telling Firefox to leave the tab as it is and to not do anything in it. 

*Unloading* the tab would have more impact. For example, say I have a video paused at 10:36. With unloading, I would probably lose that state. Say I have written a comment in Disqus, or say I am editing Wikipedia in WYSIWYG. These are currently not saved in Firefox' session store (they use "contenteditable"). So, with unloading, I would probably lose these.
I second the "freeze" implementation, #19.
If "freezing" would be made possible per tab, manually, I could manually idetify culprits in terms of the original bug question.
So, if the "CPU per tab" monitor is too difficult, implemnting "freeze" could helb in diagnostics and further help in reducing load (automatic freezing).

"Unload" would sometimes be nice but is a different thing.
(In reply to Richard Neill from comment #18)
> Part of the root cause is that there is no good way in JS for the site to
> detect when a tab is inactive (note that window->blur is no use on a
> multi-screen setup).

This tabnapper knows how to tell when a tab has gone inactive.

http://www.azarask.in/blog/post/a-new-type-of-phishing-attack/
(In reply to Howard Chu from comment #23)
> (In reply to Richard Neill from comment #18)
> > Part of the root cause is that there is no good way in JS for the site to
> > detect when a tab is inactive (note that window->blur is no use on a
> > multi-screen setup).
> 
> This tabnapper knows how to tell when a tab has gone inactive.
> 
> http://www.azarask.in/blog/post/a-new-type-of-phishing-attack/

(Ah, I just read the source, it just uses onblur and onfocus, which you just said is no use for multi-screen. Still, it's a start.)
One more recent discussion on this subject "Is there a way to identify the busy (CPU-consuming) tab in Firefox?" (http://superuser.com/questions/773976/is-there-a-way-to-identify-the-busy-cpu-consuming-tab-in-firefox)
This is about more than just a "cool feature", the lack of this feature is probably preventing bug reports to be filed : https://bugzilla.mozilla.org/show_bug.cgi?id=515352#c22
It is crucial when working with multiple tabs, without it when you have some extraordinary CPU usage you have to close all tabs and look for trouble one by one.
Don't know exactly how, but https://bugzilla.mozilla.org/show_bug.cgi?id=400120 should be linked to this bug somehow IMHO.
(In reply to alex_mayorga from comment #29)
> Don't know exactly how, but
> https://bugzilla.mozilla.org/show_bug.cgi?id=400120 should be linked to this
> bug somehow IMHO.

This is bug 400120 ...
A big part of this has landed in bug 674779. Bug 1149486 should do the rest.
Depends on: 1149486, 674779
(actually, not all the rest – we'll still need accounting for all the non-JS stuff, e.g. async reflows)
Severity: normal → S3

about:processes (see bug 1628531) covers most of this.

Status: NEW → RESOLVED
Closed: 10 months ago
Resolution: --- → INACTIVE

And who wants to have the information always available within the sidebar could install my PerfChaser extension but note that it contains an experimental API and as such only works in Nightly and DevEdition builds of Firefox.

You need to log in before you can comment on or make changes to this bug.