https://developer.mozilla.org/en-US/docs/Mozilla/Projects/We...
This video highlights some of the existing functionality:
https://www.youtube.com/watch?v=yS5ai04TP5Y&t=4s
1. a realtime recording button 2. a timeline view of events on the top 3. the ability to scan back to a console message 4. the ability to rewind to a breakpoint 5. the ability to add a logPoint in the debugger and see the messages in the console quickly
I'll second other comments on the complexity side. Our architecture works on the Operating System level, which makes it fast and non-invasive, but the difficulty level in terms of pulling something like this off is very high as you have to understand the browser architecture from the system calls it makes, to way processes behave, to graphics, the JS engine, and DevTools architecture.
I think we're in a good place in terms of getting feedback and iterating on the product. There's lot's to do and it is very exciting!
Ditto for Chrome DevTools. If I recall correctly, it’s feasible but would be a huge undertaking. Demand for the feature would have to be very large to justify the work involved.
We have a WIP patch. At the moment, we're prioritizing MVP functionality, performance, and stability.
Would it reduce the graphics, OS, etc complexity to just have the basic single function IO recording?
1. JS is dynamic and a single function can do a lot, even if you try to stub out the world.
2. from a product perspective it would be hard to communicate what is going on.
3. Perhaps console logs could cover a lot of these cases.
Does that make sense? What are you thinking of?
---
We definitely want to make it easy to visualize function calls (inputs/outputs). For instance,
- see outlier function arguments (the time the first param was null) or the function returned early...
- see outlier call sites (the time when the function was called from a different call site)
- see outlier timings (the time when the function called when some other state was null or a promise was pending) i.e. race detection
On the other side, we would love to help users see the impact of a function call. For instance,
- program slicing: the other code that was run because this function was invoked
- data tainting: the data that was either read or written to because this function was invoked