Hacker News Reader

Comment by inglor | Hacker News Reader

This is a pretty nice comment from the source that explains how it works: https://github.com/mozilla/gecko-dev/blob/11d9c7b7fa82fdfb8a...

``` // Recording and replaying works by controlling non-determinism in the browser:

// non-deterministic behaviors are initially recorded, then later replayed

// exactly to force the browser to behave deterministically. Two types of

// non-deterministic behaviors are captured: intra-thread and inter-thread.

// Intra-thread non-deterministic behaviors are non-deterministic even in the

// absence of actions by other threads, and inter-thread non-deterministic

// behaviors are those affected by interleaving execution with other threads.

```

View on HN

Sounds like Mozilla is applying the concepts they developed for their C/C++ debugger, rr (https://rr-project.org).

Exactly what I was thinking. I wonder when Chrome's going release their version!

Depends whether anybody writes it for them, or whether Google has to make it on their own.

That's exactly right

Brian Hackett collaborated early on with ROC. Here are the basic principles of Replay (https://developer.mozilla.org/en-US/docs/Mozilla/Projects/We...).

In a nutshell, replay records Firefox's OS system calls, so that that Firefox can read from the recording when replaying.

For what it's worth, the DMTCP [1] user-space checkpoint/restore system does that (and more). C/R is a way of doing coarse batch-based reversible debugging, typically of distributed HPC programs, and FReD [2] is a(n unfortunately dead) reversible debugger using DMTCP record/replay. 1. http://dmtcp.sourceforge.net/ 2. https://arxiv.org/abs/1212.5204

Thanks for sharing!

From a user perspective, we are trying to focus less on rewind and step back and more on adding logging retroactively.

The best way to think about this is when the user adds a logpoint, they'll immediately see the logs in the console.

We hope that making logging much better is a great way to help people better understand the recording.

adding log statements retroactively - that's awesome

This seems to mean that a recording done on x86_64 MacOS can't be played back on aarch64 Linux, which is a shame for something that apparently is for javascript debugging. Limitations like that are more understandable for rr, which is intended for use with native processes.

It also looks like a maintenance burden which will increase the difficulty of supporting an OS for Firefox. Stuff like that causes Firefox to drop support for an OS, and it makes developers hesitant to add support for an OS.

System calls can do all sorts of crazy stuff behind your back. Think of ioctl and fcntl. Just knowing what memory they modify is difficult. It's been lots of trouble for tools like strace and rr. Hopefully you won't encounter worse, like vfork and clone.

I think WebKit has a similar feature, though it seems to work at a higher level than the one Firefox has (disclaimer: I haven’t used it, so I could be totally wrong). From what it looks like, Firefox hooks things at a much lower level and currently relies on some very Mac-specific features like Mach exception handlers (I’m actually curious as to how it works: is there a file or two I can glance at to skim the implementation of these?) Why perform the interception at this level? How do you plan to implement this on platforms that don’t have equivalent task APIs, e.g. Linux?

What is non-determinism in the browser?

Inputs that are either random or subject to change (api responses, user prompts i.e.)

Based on the grandparent, it sounds like race-conditions and random number generation fit the bill.

My guess is that "optimisations" (shortcuts) in calculating the final layout, mean that the final layout is not entirely deterministic.

It probably varies slightly, due to the entangled nest of dependencies that is responsive HTML rendering...

I don't know but if I had to guess: order of responses coming in from the server, interleaved with timer events and user events.

Once source comes from the memory allocator, and the pointers it gives out.

If you have an ordered map of pointers (e.g. std::map<void*>), iterating over the map will not be deterministic because the pointers given by a (regular) allocator are not deterministic.

This may be true in c++ but I believe is not in JavaScript. The language defines iteration order over keys of an object to be the insertion order (except numeric keys which are in ascending order). Not sure if there's anywhere that iteration order is actually nondeterministic that's allowed by the spec.

Nondeterminism is every place where information can enter your program from the outside world.

It's random numbers, the system clock, data off the internet, and input events from the user.

What it sounds like is that Mozilla has come up with a debugging environment that bottles all that nondeterminism up into a neat little package so that it can replay a specific run of your program any time you want.

Reply on news.ycombinator.com