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

NEW
Unassigned

Status

()

Firefox
General
--
enhancement
10 years ago
8 days ago

People

(Reporter: Mike, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(e10s-)

Details

(Reporter)

Description

10 years ago
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.

Updated

9 years ago
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

Updated

8 years ago
Blocks: 515354

Updated

8 years ago
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.

Updated

7 years ago
Blocks: 515352

Updated

7 years ago
Duplicate of this bug: 576892

Updated

7 years ago
Duplicate of this bug: 340372

Updated

7 years ago
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.
Duplicate of this bug: 610165
Duplicate of this bug: 685120
Depends on: 687724

Updated

6 years ago
Duplicate of this bug: 711650

Updated

6 years ago
Depends on: 710927
Summary: Add CPU and RAM monitor on a per-tab basis → Add statically-updated, per-tab CPU and RAM monitor

Comment 11

5 years ago
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.

Comment 12

5 years ago
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.

Comment 13

5 years ago
The last 2 comments are describing bug 662768

Comment 14

5 years ago
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.

Updated

5 years ago
Duplicate of this bug: 662768
Mass tracking-e10s flag change. Filter bugmail on "2be0fcce-e36a-4e2c-aa80-0e3d33eb5406".
tracking-e10s: --- → +
tracking-e10s: + → -

Comment 17

3 years ago
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).

Comment 18

3 years ago
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).

Comment 19

3 years ago
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.

Comment 20

3 years ago
(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.

Comment 21

3 years ago
(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.

Comment 22

3 years ago
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.

Comment 23

3 years ago
(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/

Comment 24

3 years ago
(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.)
Duplicate of this bug: 1079299

Comment 26

3 years ago
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

Comment 28

3 years ago
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.

Comment 29

2 years ago
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)

Updated

a year ago
Duplicate of this bug: 1272308

Updated

9 months ago
Duplicate of this bug: 1298663
You need to log in before you can comment on or make changes to this bug.