It's much too hard to debug the common error of leaking timers, especially
setInterval() timers right now. As a developer I want to be
able to click a button in the inspector and have it list out every pending
timer along with:
- whether it's a setTimeout or a setInterval
- the delay time specified and the clamped value
- how many times it has fired so far (for setIntervals)
- a timestamp and the JS stacktrace when it was set
- what code will be executed when it fires (either the specified string or
the contents of the specified function)
This would make debugging a few recent problems in google properties about
Upstreamed from Chromium's http://code.google.com/p/chromium/issues/detail?id=24389
Neat idea! I wonder where this could live in the UI?
I agree, this sounds good.
Why not extend this to all events, not just timer-related? As well as seeing the event listeners that have been set, it would be useful to see a time-line of the events being fired.
As I understand it, this feature request is about memory leaks detection (retainers profile) and debugging indirections in the control flow. It is not about events time line in general. So I think we should keep the scope narrow.
The straightforward approach is to introduce a new profile type that allows taking snapshots of all pending timers. Snapshot will present all the information requested in this feature request. This is a very specific feature, but it seems there is a need in it. I see no other places in the UI to display detailed information about pending timers.
As we implement it, we will collect information about timers that would allow implementing following more general features as well:
- Show timers along with other registered event handlers in the retainers heap profiler as the roots.
- Glue original setTimeout's stack to the functions invoked on timer. No scope variables obviously, but the real control flow would be useful.
The original motivation of this bug was a bug where setInterval() was being called without the corresponding clearInterval(). It's a bit baffling right now to try to figure out where the interval timers are coming from especially if it's a slow or difficult to reproduce leak.
Created attachment 141242 [details]
Current Script Panel - Controls Pane
Attachment shows that we can now break at all setTimeout/setInterval/clearTimeout/clearInterval. Which helps the original problem.
Personally, I think that is still too noisy though. I am not certain of the data structure we use for timers, I think of it as array of Timer objects and Interval objects with a few properties.
If it would be expensive to display these in the Scripts panel, it would be nice to be able to query that data:
[ *Timeout, *Timeout, *Timeout, *Timeout ]
inited: '05-12-2012 13:00:00'
Actually, it would nice if that data was exposed to the browser JS too, but there might be security implications.