Time-Travel Debugging for JavaScript/HTML Applications

Play Time-Travel Debugging for JavaScript/HTML Applications

The Discussion

  • User profile image


    Great stuff! Are there plans to make this available to the public?

    On a more technical note, when you're replaying the recorded action, is it safe to execute every action, including side effecting (and potentially not idempotent) functions?


  • User profile image

    @md70: Hi and thanks for the questions. We are working with some great people on the product teams to figure out how to turn the experimental system into something that we can make public but, at this point, we don't have a concrete timeline for when this could happen.

    On the technical question, you are right to observe that we don't want to re-execute some calls that have side-effects. For example resending an XHR request which may be unexpected at the server. To handle this we do two things. First is that during the original execution we remember the result of these side-effecting operations. In the case of XHR what the responseText, responseType, etc. values are. Then when we replay the program and reach the send call we transform it into a nop (i.e., we don't actually send the request). Later when the program reads, say the responseText property, we return the value that was recorded in the original program execution.

  • User profile image

    So this is what we got out of mugshot.js. I saw the Video back at Mix 11 from James, and this along with the Siloing talk was (to me) the most exiting stuff of the conference, because it was promising something HUGE for testing/software development scaling, esp. in a legacy system, where this non-softwaredesign dependent way of record/replay for complex test runs, completely isolated from the "inner" complexity of the software, just dependent on the limited API of the browser, pays of once a certain Software complexity is reached.  This + Opensource = win for everybody. But I guess this is not going to happen on your side, as it's MSR territory, like your PEX-driving constraint resolver. .. some things will probably never change.

    I have my theories around this concept, I think you are up to something much bigger that just "historical debugging" suggests. I think that this record/replay could spawn a new way of testing that we don't have a name for, yet. In a way it's the jang to the Unittest jin, a dual principal, the domain would be in-memory testing. And what you call "nondeterministic behavior" I would call "out-of-process communication" (in the case of the browser "out-of-mainthread communication"" or "access to mutable global state out of programmers reach". As far as I can tell, this is the same principal.

    Back in the days, you mentioned the problem of latency replay in the mugshot.js paper, and needing a proxy/external tool to fix this. Isn't that something that serviceworkers could fix in the future?

  • User profile image

    this seems like *again* MS is headed for a bloated heap of none-functional-browser.

    please guys, can you just walk before you try and run... better yet, crawl before you try and walk! you have soooooo much work to do to produce a browser that works properly and doesn't render pages that look like a drunk five y/o with a crayon drew the page

    as a developer with 25 years experience (on Windows with VS) myself i understand the issues you've faced over the years and relate to the uphill struggle you have to get respect in the browser space...

    ... having said that you are just dooming yourselves right now by trying to bite of more than you can chew. think modestly and just try to do the basics.... the ie team has caused so much damage for the MS brand i don't want to see it continue into the future!

    all the best

  • User profile image

    @paul: And what's the issue with using "report website problems" now that such is available in IE (OK I think I know the answer: bunch of internal/secure sites are not working anymore or sending stuff is prohibited/white lists etc)

  • User profile image

    er, this is not a new idea - although it is new to the browser.

    It's already available for Java (see Chronon time travelling debugger) as well as C/C++ (rr from mozilla and undodb).

    Finally, it would be ideal if the enabling technology for this was exposed as an API on top of the JS VM rather than as a tool that's only available to MS engineers.

  • User profile image

    Well, that's neat! Waiting for public release.

  • User profile image

    please make this available in VS for c# :)

  • User profile image

    @ray: you are correct that time-travel debugging has a long history of previous work. In a paper we published last year we review work on the topic going as far back as 1988. A major challenge in using previously described systems is the large performance impacts they can have, frequently in the range of a 2x-10x slowdown, which makes them impractical to use on a day-to-day basis. The major advance we made is lowering the overhead of running a program in time-travel mode to the point where it is negligible from a developers perspective. As described in the video, and in the paper I linked, we are able to fundamentally reduce the overhead costs by working at a higher level in the system (JS/HTML application vs. entire C++/Browser/OS stack) and leveraging existing features in the managed JS/HTML runtime (type-safety and GC).

    Your point about providing an API for the enabling technologies is an excellent one. As James mentions in the video we are excited about the possibilities of this new interrogative layer of virtualization and, hopefully, we will have more to say about this soon.


  • User profile image

    This sounds similar to Visual Studio Ultimate edition's Intellitrace feature... correct me if I'm wrong

    @TheBitBender: If I'm right, it's already there for C#~

Add Your 2 Cents