Frequently Asked Questions

Brian Burg edited this page Mar 29, 2014 · 4 revisions


Can I demo Timelapse without building from source?

No, but it will soon be possible to do so from the WebKit nightly binary builds. This is tracked here:

Does Timelapse slow down the user experience?

In practice, usually not.

Because Timelapse records inputs to a program instead of the actual instructions executed, relatively little time is spent capturing and saving data during recording. The amount of data captured scales with user input, not CPU time. Even for applications with high rates of user input (such as video games), Timelapse doesn't introduce a noticeable decrease in performance.

On program replay, Timelapse can replay the execution much faster than the speed at which it was recorded. This is because page resources are loaded from memory instead of over the netwrok, "user delay" can be elided, and the results of some platform functions can be memoized instead of re-executed.

How big are the Timelapse recordings?

All HTTP requests and responses are captured, so the recording's size is the sum of all resources requested during the execution, plus the size of each nondeterministic input. Most such inputs are really small and highly compressible. The total size of the recording will scale with the number of program inputs, such as network requests, user mouse/key input, and timer callbacks.

In our preliminary performance evaluation, applications with high rates of user input (such as timer-based video games) generate at most 250KB/minute of input, and this can be compressed to under 50KB for storing or transmitting recordings. These numbers do not include network traffic/page resources, which can also be compressed (and generally dominate the size of recordings).

Will replaying an execution cause network traffic?

On replay, network requests are intercepted by an in-browser network simulator.

External servers will not re-receive network requests during replay. A network-level record/replay simulator captures all HTTP headers and traffic when recording, and only allows the same requests to occur on replay. From the web page's point of view, the external server appears to behave the same on recording and replay, though on replay the network traffic actually originates from the recording.


Does Timelapse work on Linux or Windows?

Right now, no. It is actively developed for the Mac port (i.e., OS X desktop, not iOS). We (at the University of Washington) do not have the engineering time available to add support for other WebKit ports. Other platforms will definitely not work out of the box. That said, the implementation approach for Timelapse is platform-independent and does not overly rely on platform-specific APIs. See the next question for details.

How much work is necessary to enable the Web Replay feature for other WebKit ports?

It's not a trivial amount of work, but not particularly challenging either.

There are several platform-specific parts of code to implement, in order of increasing effort:

Build system

Each platform has its own build system and/or build settings. Web replay is behind the ENABLE_WEB_REPLAY flag, which toggles compilation of the replay infrastructure. So, you will need to ensure that feature can be toggled on, and the build system is aware of feature-specific files. For example, most files in Source/WebCore/replay/ are not added to CMakeLists.txt. See Adding Files To WebKit for more details.

Embedder-specific nondeterminism

Each embedding application/library uses a different subset of the WebKit/WebKit2 embedding APIs. In some cases, embedders may use API calls that have not yet been piped through the user input bridge between WebCore and WebKit2. Fixing this could be as simple as calling a different method, or as hard as adding/controlling an entirely new source of nondeterminism.

Platform-specific nondeterminism

Each platform introduces its own sources of nondeterminism, which must be controlled for record/replay to work correctly. For example, the Timelapse code specific to the Mac port exists to memoize accesses to the system-shared cookie jar.

What language is Timelapse implemented with?

The infrastructure for recording and replaying is a part of the WebKit engine, which is mostly written in C++. The developer tool UI is written using HTML, CSS, and JavaScript. Accompanying scripts and tools are predominantly written in Bash and JavaScript.

How do you write tests for Web Replay functionality?

For replay infrastructure, we write regression tests that starts up a test page, records some interaction with it, and compares replay output to captured output. WebKit's test harness provides access to test both the models and controllers Web Inspector UI, and the C++ backend to which it communicates. See the WebKit wiki page for more details.

How much work is necessary to port the Web Replay feature to Google Chrome?

Many of the mechanisms would be the same, but it would be several months' work to port the replay backend.

Can Web Replay be ported to Firefox/Gecko?

It's possible, but not straightforward. It would require substantial redesign because the architecture is different.

Contributing and Reusing

How can I contribute patches to the project?

Development of core replay infrastructure happens directly on WebKit trunk. See for guidelines on contributing to that project. Be sure to file it as a Web Inspector Bug.

More experimental features are developed on this Github project, which hosts research offshoots of the main replay infrastructure. Please open an issue or pull request if you have something to contribute. Definitely get in touch before doing significant work, as we make no guarantees about what happens in the Github repository.