580880 - chrome JS access to setTimeout enumeration

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[John J. Barton]

Gradually Firebug has learned how to stop JS and Web page events when we halt on a breakpoint. However, this causes Web apps to fail because setTimeout events (apparently) fail if you are halted.  See:
Issue 3264:  	 setTimeouts are skipped while stopped in the debugger
http://code.google.com/p/fbug/issues/detail?id=3264 

Boris says there is SuspendTimeouts but no way to call it in JS. Ideally it would stop the timer until we resume it. This would allow programs to be correct even if we halt them.

Even better would be a way to enumerate the pending timeouts. We just need access to the functions and delay time. Then we can help devs by showing them what timeout functions they have set and allowing them to eg set breakpoints in these functions. That would go a long way to making setTimeout code less mysterious.

Comment 1

[Boris Zbarsky [:bzbarsky]]

smaug, would it make sense for nsDOMWindowUtils::SuppressEventHandling to SuspendTimeouts on the window?  Or do we need to add a new API here?

Comment 2

[Boris Zbarsky [:bzbarsky]]

The enumeration sounds like a good idea too, but would need to be separate from the issue of timeouts firing while debugging, right?  You need that part no matter what happens with enumeration....

Comment 3

[John J. Barton]

Rather I would say: no need to bother opening a bug for enumeration until we can suspend ;-)

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

DOMWindowUtils could have just a new method for suspending/resuming timeouts.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Sure; the question is whether suppressEventHandling should do it automatically or whether we should create said new method.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Turns out I need this for the test for bug 581072 anyway.

Comment 7

[Sebastian Zartner [:sebo]]

Any news on this one?
Please also have a look at http://code.google.com/p/fbug/issues/detail?id=3017, which needs this to be processed.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> Any news on this one?

Chrome access to suspending timeouts is implemented; see bug 581072.  John, do you want to morph this bug to cover enumeration, or file a clean bug (this is why we do one bug per problem!).

Comment 9

[John J. Barton]

I've added bug 581072 to our Firebug 1.7 todo list http://code.google.com/p/fbug/issues/detail?id=3372 and changed the title here to focus on enumeration.

My summary lies however because we also need to list the objects bound by setTimeout functions:
    function bar() {
      var foo =  window.myProp;
      setTimeout(function xx(){ alert(foo); }, 5000);
      delete window.myProp;
    }
    bar(); 
    // now who is still pointing to the object myProp refed?

But you can tell me this is another bug also?, because the same problem affects event handlers even more important.

Comment 10

[Boris Zbarsky [:bzbarsky]]

>    // now who is still pointing to the object myProp refed?

The function passed to setTimeout is.  I believe, in particular, that the parent of the function object (see jsParent on jsdIValue) will hae a property called "foo" on it.  Though there may be various cases where we optimize things away (e.g. if you didn't use foo in the function, we wouldn't hold a ref to it from the function).

If you want nicer accessors to find values in scope in given functions (so following the scope chain and proto chains both), that would be a separate bug, yes...

Comment 11

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.