3 ms·

WebReplay – Time Travel Debugging for Firefox

139 points by octosphere 8y ago

jasonlaster11 8y ago
Here are some docs on how to try it in nightly. https://gist.github.com/jasonLaster/1e220992c294a571dd9b59abd084ccf2 https://gist.github.com/jasonLaster/1e220992c294a571dd9b59ab...
- mauricioc 8y ago
  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!
  - mintplant 8y ago
    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.
    - jasonlaster11 8y ago
      That's amazing!
  - dblohm7 8y ago
    Brian is a brilliant guy. I'm thrilled that web replay is working!
  - ksec 8y ago
    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 ) Good thing Mozilla manage to kept him around.
azhenley 8y ago
Is this based on Brian Burg's work? His dissertation work was Timelapse [1] which looks like it was pushed to Webkit [2] for Safari. [1] https://github.com/burg/timelapse/ https://github.com/burg/timelapse/ [2] https://github.com/burg/replay-staging https://github.com/burg/replay-staging
- mccr8 8y ago
  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.
ddtaylor 8y ago
> Currently only macOS is supported. Does anyone know why this is or how to get this working on Linux?
- dblohm7 8y ago
  Probably because the work hasn't been done yet. It's a very small team.
  - jasonlaster11 8y ago
    Yep. It's on the roadmap, but the recording is done at the OS level, so Windows and Linux will require some work to get support.
- mccr8 8y ago
  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.
kodablah 8y ago
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.
- Groxx 8y ago
  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))

139 points by octosphere 8y ago

Here are some docs on how to try it in nightly. https://gist.github.com/jasonLaster/1e220992c294a571dd9b59abd084ccf2 https://gist.github.com/jasonLaster/1e220992c294a571dd9b59ab...

mauricioc 8y ago
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!
- mintplant 8y ago
  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.
  - jasonlaster11 8y ago
    That's amazing!
- dblohm7 8y ago
  Brian is a brilliant guy. I'm thrilled that web replay is working!
- ksec 8y ago
  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 ) Good thing Mozilla manage to kept him around.

azhenley 8y ago

Is this based on Brian Burg's work? His dissertation work was Timelapse [1] which looks like it was pushed to Webkit [2] for Safari. [1] https://github.com/burg/timelapse/ https://github.com/burg/timelapse/ [2] https://github.com/burg/replay-staging https://github.com/burg/replay-staging

mccr8 8y ago
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.

ddtaylor 8y ago

> Currently only macOS is supported. Does anyone know why this is or how to get this working on Linux?

dblohm7 8y ago
Probably because the work hasn't been done yet. It's a very small team.
- jasonlaster11 8y ago
  Yep. It's on the roadmap, but the recording is done at the OS level, so Windows and Linux will require some work to get support.
mccr8 8y ago
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.

kodablah 8y ago

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.

Groxx 8y ago
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))