Web Replay's goal is to make debugging and improving web sites fast, fun, and easy. This page walks through some of the exciting new workflows that are now possible.

Time Travel Debugging

Once developers have a Web Replay recording capturing a bug, they must analyze it to determine the bug’s underlying cause. Web Replay provides a suite of new features to help with this process. These features extend the browser’s standard developer tools with the ability to travel through time: Web Replay can rapidly reconstruct the browser's DOM, CSS, and JS state at any point in the recording, allowing developers to directly work their way backward to the underlying cause.

It isn’t necessary to create and submit a recording in order to use these new features. Developers can start recording a page, open the developer tools, and immediately analyze the behavior that has happened so far.

Below, we describe these new analysis features by showing how they improve debugging workflows in comparison to standard tools.

Inspecting the DOM

The standard developer tools included in web browsers are great for inspecting the DOM and CSS state on a page, but they are only able to inspect the current state of the page. This makes it hard to understand how the DOM changes over time, especially the causes of glitches on a page or how the page responds to user interactions like mouse hover events.

Web Replay’s DOM inspector offers the same functionality as the standard DOM inspector, but allows the DOM to be inspected at any point in the recording. This includes every rendered frame, and every executed JS statement.

Studying console errors

Bugs on a page are often associated with errors or other problems logged to the console. Looking at the console output in the developer tools will show these errors, but this is rarely enough to figure out the error’s underlying cause.

When using Web Replay, the console output will be the same as with standard developer tools. Every error and logged message can be clicked on, however, which jumps through time to the point when that error or log occurred. All DOM, CSS, and JS state at that point can be inspected, and the stepping buttons and other navigation tools can be used to see the execution state at nearby JS statements and understand why the error occurred.

Try this demo

Using console.log()

Logging messages to the console is a common practice when investigating bugs. New calls to console.log() are added to the page, then the developer reproduces the bug, studies the output of those calls to get a better understanding of what is happening, then probably has to add more console.log() calls and repeat the process several times. This is slow and cumbersome, especially with bugs that reproduce intermittently, where the process will either take much longer or fail entirely if the bug stops reproducing (a Heisenbug).

We feel that logging messages to the console is very helpful when investigating tricky bugs, and have added a feature to Web Replay to make this workflow much more efficient. Standard developer tools let users set logpoints at JS statements, which are like breakpoints but log a message to the console instead of pausing execution. Normally, logpoints only apply when the statement executes in the future, and the above cycle of repeatedly reproducing the bug is still required. When using Web Replay, logpoints apply throughout the recording: a message is added to the console for every time the logged statement has ever executed. Developers can add or remove logpoints as needed to track down the underlying cause, without having to make new recordings.

Try this demo

Using breakpoints

Setting breakpoints and pausing at them is commonly used to inspect DOM or JS state at specific points in a page’s execution. When tracking down a bug with standard developer tools, a developer will set some breakpoints and run forward between them as they study how the program’s state changes. If they move past the point they were interested in then they need to reload the page and start over, and if the bug is intermittent then they won’t know whether the bug will even occur later on.

Web Replay improves on the use of breakpoints by allowing execution to run in either direction when finding hits. Developers can run forward to the next time a statement is hit, or they can rewind to the previous time. This eliminates the difficulties above.

However, we feel that Web Replay’s logpoints provide an even larger improvement over breakpoint based workflows. Messages added by logpoints can be jumped to in the same way as for other console messages, letting developers go straight to the point they want to and inspect state there as if they had stopped using a breakpoint.

Stepping through JS

Stepping buttons are used in standard development tools for fine scale navigation within a JS frame. Stepping is subject to the same issues as navigation using breakpoints: developers might step past the point of interest and need to start over, and they won’t know if an intermittent bug will occur later. They can also be annoying to use if there is a lot of JS execution in a frame and many steps are taken.

Web Replay offers several improved workflows for understanding how code executes within a frame. First, in addition to the normal forward stepping buttons there is now a reverse step button, which steps back to the previous statement and makes it easy to recover if the point of interest was stepped past. Second, a timeline for the current frame is shown which developers can use to quickly scan through all the steps executed in the frame and reach the point they want to.