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

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?

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