On Wed, Apr 16, 2014 at 7:14 AM, Till Schneidereit < [email protected]> wrote:
> On Wed, Apr 16, 2014 at 1:52 AM, Ehsan Akhgari <[email protected]>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.) > The main idea behind a record and replay framework is to record the results of API calls to the environment that you don't control and during replay, respond with the same observable effect. For rr, this would be the OS level syscalls (among other things). For a JS record and replay, it would be things such as DOM API calls, event/promise callbacks, JS APIs such as Date.now(), etc. If I understand the above correctly, is this the part which caused people to decide that this is not feasible? I agree that it would be a significant amount of work, but I don't understand why we could not implement the record and replay idea by replaying the same observable effects to the JS code we're running. Cheers, -- Ehsan <http://ehsanakhgari.org/> _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
