On Wed, Apr 16, 2014 at 1:52 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com>wrote:
> On 2014-04-15, 7:14 PM, Gijs Kruitbosch wrote: > >> On 16/04/2014 00:05, Robert O'Callahan wrote: >> >>> We just released rr 1.2 and I think this would be a good time for >>> people to >>> try to use it for one of the tasks it was designed for: debugging >>> intermittent test failures. >>> >> >> This is awesome! Three questions: >> >> 1) Is anyone working on something similar that works for frontend code >> (particularly, chrome JS)? I realize we have a JS debugger, but >> sometimes activating the debugger at the wrong time makes the bug go >> away, and then there's timing issues, and that the debugger doesn't stop >> all the event loops and so stopping at a breakpoint sometimes still has >> other code execute in the same context... AIUI your post, because the >> replay will replay the same Firefox actions, firing up the JS debugger >> is impossible because you can't make the process do anything. >> > > I think you want to consult the spidermonkey hackers to see how feasible > that will be... > At the JS work week in Toronto in late March, we discussed this. Unfortunately, that was one of the relatively few sessions for which no protocol exists. :( The gist of the results was that, sadly, this is incredibly hard to pull off, if at all. Pretty much any JS program of meaningful size has complex interactions with the DOM and the network. For those, we can't prove whether it's possible to replay instructions without completely changing the outcome. I guess if we were to implement a complete recording/replaying shim of the DOM and network APIs, we could overcome this issue. It's certainly a very different project from rr, though. (Just for the record: I would *love* having this capability, and was very disappointed when the conversation converged on this conclusion.) _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
