Bug 30257 – Web Inspector: show DOM timers that are pending at a given point on the timeline

• Status: UNCONFIRMED
• Component: Web Inspector

[Pavel Feldman]

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
10,000,000x easier.

Upstreamed from Chromium's http://code.google.com/p/chromium/issues/detail?id=24389

[Timothy Hatcher]

Neat idea! I wonder where this could live in the UI?

[Patrick Mueller]

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.

[Pavel Feldman]

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.

[James Robinson]

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.

[Rob Colburn]

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:

console.getTimeouts()
[ *Timeout, *Timeout, *Timeout, *Timeout ]

console.getTimeouts()[1]
*Timeout
 ID: 1
 inited: '05-12-2012 13:00:00'
 delay: 200
 code: ''
 func: function(){}
 scope: *Object
 params: []


Actually, it would nice if that data was exposed to the browser JS too, but there might be security implications.

[Radar WebKit Bug Importer]

<rdar://problem/19281436>