I feel like I should point out this 20+kLOC project is the work of just one engineer (Brian Hackett), although of course several people helped with reviews and feedback. It's very impressive and inspiring work. Major props!
When I was interning at Mozilla, we had a joke about tracing back the history of pieces of code via recursive `blame` (to get more context on them), and how so many roads in the JS engine led back to a bhackett commit.
Brian Hackett... His name rings a bell. Was he the one who bring up all the Javascript Monkeys? I cant even remember those Javascript Monkey names, they were at least a few of them in early 2010s. I used to follow the Firefox performance work, I think he started way before MemShrink has happen and when everyone though JS performance was the holy grail of all things web page and Firefox Performance. ( Which turns out to be not true )
More importantly than replay, I'd say is snapshotting. At a high level, if extension writers et al are given an API to snapshot a page at this level there are many neat things that can be done. One of the biggest is pausing. While some websites will detect long pauses as out of sync most might not see it as any different than a network hiccup, but in general I would like to "pause" any tab not in active focus (maybe except a whitelist like my email). All of the suspension tools in browsers that I'm aware of just store the URL and kill the page, just to reload from that URL in "restore".
I can think of about a dozen other use cases for browser-tab serialization (i.e. snapshotting), esp wrt distribution, remote use, caching, render-and-stop read-only pages, etc.
The Jason Laster gist implies it should cover this out-of-the-box: you can rewind to when logs were emitted.
(or if it doesn't offer an easy way to do that: I assume a conditional breakpoint with that log message -> rewind until it is triggered will cover the same feature (and far more))
The section "Comparison with other projects" in the linked article has a comparison to other replay efforts, including what was done for WebKit. I think WebReplay is lower level than the WebKit work, but higher level than rr, which gives you various tradeoffs.
WebReplay requires recording and replaying a lot of low level system specific stuff, like system calls, IPC traffic, stack, and the heap. The "Porting" section of the linked article talks about this. I think the design is intended to support working on different operating systems (as compared to rr which is likely to only ever work on Linux), but porting will require additional work.
https://gist.github.com/jasonLaster/1e220992c294a571dd9b59ab...