We need some kind of way to see the causes of responsiveness problems in the browser that is easily accessible to users, to aid with tracking down problems. "When I go to site X, my browser uses a lot of memory!" is a frequent style of MemShrink bug report. With about:memory, it is possible to get more information out of users. We need to be able to gather similar information about responsiveness, without requiring that users set breakpoints in GDB. Even when users are technically sophisticated enough to do so, the harder it is for them to figure out what is going on, the less likely they will be to investigate further, file bugs, etc. Unlike memory, snappiness has a temporal component, so it would be along the lines of showing all the events in the last minute or so that caused pauses. Someone suggested that some kind of timeline display of what happened, possible with dependency between events, could be useful. A format that can be easily pasted into a bug report by user who doesn't understand the contents of the report is also very useful. Existing related facilities: We already have javascript.options.mem.log in about:config. When set to true, the cycle collector and garbage collector dump out information to the error console about how long they took, how many objects they collected, why they were triggered, etc. This is a good start, but there are many other sources of pauses in the browser, and this configuration option is fairly obscure. A great deal of responsiveness-related telemetry is present in the browser and more is being added all of the time. The about:telemetry addon allows users to see what has been gathered, which can provide a window into browser behavior. This lead directly to the discovery of Bug 699668 when I noticed my sweep times were long. However, the aggregated nature of telemetry limits the usefulness in long browsing sessions where there is a sudden change in responsiveness. Figuring out problems in long-running browsing sessions, which are hard to reproduce, is difficult. It would be nice if we could somehow leverage telemetry data.

Nice idea. Two immediate questions: - What information do you show? There's heaps of stuff that you could show; the scope is much broader than about:memory. - How do you collect that information cheaply? With about:memory you only have to take the measurements (with a handful of exceptions) you load about:memory. That won't work in this case.

(In reply to Nicholas Nethercote [:njn] from comment #1) > Nice idea. Two immediate questions: Good points. This is fundamentally different from about:memory in that it probably is impractical to have some kind of "time-unclassified", where somehow the goal is to figure out what the browser is doing every 1ms, and then you can see where pauses are. Instead, I think a better starting point is instrumenting specific known causes of pauses, and dumping out that information when they happen. This is already done in a number of places for telemetry, so the additional overhead would be converting data to strings, not gathering it. At least, that's what I was thinking.

Though I think somebody is working on a profiler that could be lightweight enough to be left in a release build, which I guess would give you a sort of "time-unclassified" detailed view of what is happening.

How about calling it about:pauses instead?

I'm the reporter of bug 504770. I don't really care what the URL is called, my concerns are those two: 1. We need to be able to generate the report while Firefox hangs. This either means that the report needs to be run by a second instance of the JavaScript engine in an independent thread or that the report needs a way to disable all other threads form hogging the CPU while it runs. 2. When Firefox hangs, the report should come up automatically. There is no point to run it afterwards (when the effect is over) and I don't want millions of people to remember "type about:pauses in the location bar when Firefox hangs". When it happens, Firefox has been a bad puppy and it has to make up for it. :-) Offering the user support (like the "Script is unresponsive" dialog) is going to soothe some ragged emotions.

You might be interested in bug 429592 (which is a hang detector for Nightly that uses an additional monitoring thread to crash the browser when there's a 30 second hang, and submits a crash report to Mozilla so we can see what is happening), and its followup bug 705888, that will do the same without crashing the browser. I think that may actually be more along the lines of what you are thinking of. The hang detector is actually live right now in Nightly (though they are thinking of turning it off again to deal with the hangs it reported). If you go to this URL and look at the crashes that start with "chromehang |", you can see what it has reported so far: https://crash-stats.mozilla.com/topcrasher/byversion/Firefox/11.0a1/7 There are also the blocking bugs in bug 429592, for detected hangs that have bugs filed now. This bug is probably going to focus more on sub-30-second pauses, which are annoying, but not as awful. Taras and his team are also working on a lot of telemetry to gather mass stats about various sources of pauses.

(In reply to Aaron Digulla from comment #6) > I'm the reporter of bug 504770. I don't really care what the URL is called, > my concerns are those two: > > 1. We need to be able to generate the report while Firefox hangs. This > either means that the report needs to be run by a second instance of the > JavaScript engine in an independent thread or that the report needs a way to > disable all other threads form hogging the CPU while it runs. > > 2. When Firefox hangs, the report should come up automatically. There is no > point to run it afterwards (when the effect is over) and I don't want > millions of people to remember "type about:pauses in the location bar when > Firefox hangs". > > When it happens, Firefox has been a bad puppy and it has to make up for it. > :-) Offering the user support (like the "Script is unresponsive" dialog) is > going to soothe some ragged emotions. We've been working on something similar to this, except the part about needing a second instance of the Javascript engine. These are off course very ambitious goals and we still have several technical challenge to complete before we can get there. See tracking bug 683229.

p2 - nice to have

This is basically a dupe of about:jank or bug 715774.