Use case: 1) Set 2 breakpoints in JavaScript code, run until the first one 2) press a "record" button and restart Code runs until the second breakpoint and saves the states of the program 3) when reaching the second breakpoint, a UI appears and allows to inspect the program at any point in time between the 2 breakpoints.

In December, I wanted to work on that as a side project. I once popped up on jsapi to mention that and had 2 calls with jorendorff and jimb (in CC) to discuss limitations of the new Debugger API. What needs to be recorded: 1) Changes to objects properties => I initially planned to content objects by proxies to capture this information. Given some compartment and probably some performance issue, jimb&jorendorff suggested to rather use a watchpoint API. See bug 638044 and bug 638053. 2) Changes in function scopes This could be done in 2 different ways: * an "onset" event when a variable gets a new value * snapshots of variable values generated (hopefully lazily) by the JS engine. 3) An idea mentionned by jimb was to design an API that different components could implement. When necessary, the debugger could ask this component to get back to an earlier state. Such an API would have the advantage of distributing the work and also to put the responsibility of "get back in a past state" to each component.

This could be an interesting experiment. I could see this requiring very large hunks of memory to store all the stack frames and be somewhat unpredictable in some cases. You'd want to isolate the browser from responding to additional events (which we do anyway) during a replay phase. I guess if you could alter some of the entry conditions (i.e., change state on some objects before beginning the replay) you could see how a particular section of code responds with different entry conditions, but without some fairly rich tools to edit and modify those objects, that type of setup maybe more painful than simply rerunning the code under breakpoint control.

This sounds like the reverse debugging that GDB has and seems useful. I would enjoy being able to do a step-into-PREVIOUS-function at a breakpoint. There are a couple of videos online of how something similar works in Flash Builder. (In reply to Rob Campbell [:rc] (:robcee) from comment #2) > I could see this requiring very large hunks of memory to store all the stack > frames and be somewhat unpredictable in some cases. Maybe there's a way to "cheat", like save only the minimum information that is required to bring back state, or not save a thing and re-execute the script every time till the previous breakpoint? Of course the later would have issues with randomness.

(In reply to Dionysios G. Synodinos from comment #3) > (In reply to Rob Campbell [:rc] (:robcee) from comment #2) > > I could see this requiring very large hunks of memory to store all the stack > > frames and be somewhat unpredictable in some cases. > > Maybe there's a way to "cheat", like save only the minimum information that > is required to bring back state, or not save a thing and re-execute the > script every time till the previous breakpoint? Interesting. Just save the state of the first breakpoint and restart the program in order not to have to store too much information. It's not cheating, it's taking advantage of the classic time/space tradeoff :-) > Of course the later would have issues with randomness. I'm confident all sources of non-determinism (Math.random, date.now, event timestamps...) can be fully tracked and reinstated when necessary. It would take memory, but combined with what you described above, it sounds it could be largely reasonable.

Have a look at Timelapse: http://www.cs.washington.edu/homes/burg/projects/timelapse/