Clone this wiki locally
These ideas are proposed by Timelapse project developers as features that would enhance usability, scope/use cases, and tool stability. They can be vague, incomplete, or speculative. All ideas involve a substantial engineering effort; many include design and evaluation efforts. Research projects have a more straightforward research contribution, but engineering projects also explore mostly new ground and could result in interesting results.
Have another idea or want to do your own research using Timelapse? We highly encourage you to contact us for feedback.
These projects are being pursued to some degree, so please inquire to see the current status is.
Project: Capture/display screenshot previews of recordings
Developers can use web replay to seek to any point in a captured execution. If a developer wants to use Timelapse to investigate a bug that manifests visually, they must play back or seek through the recording until they see the output they were looking for. It would be much more efficient if instead, they could preview the output (such as the timeline "scrubbing" in Camtasia or Youtube players) at a particular time without actually replaying.
This project would be to add support to automatically capture screenshots during an execution and display them in the UI. Screenshots must be accessible in the tool and have high enough fidelity to be useful, but not so large as to hurt performance. They must also support use cases where a developer would benefit from visual feedback.
(Capturing of screenshots in the backend is already implemented, but the screenshots are not used in the UI)
Project: Opt-in, always-on capturing of executions
Timelapse currently only captures executions when the user explicitly clicks a "start capturing" button. The recording overhead is low enough that it should be possible to passively capture executions while developer tools are enabled. With this capability, Timelapse would be much more useful for reproducing field failures. Upon encountering a bug, a non-technical user could simply select the most recent recording and send it as part of a bug report.
To implement passive capturing, you must figure out how long to hold on to recordings before discarding them, and how to split browser sessions into discrete recordings. There are also some UX issues: indicating that passive capturing is enabled, browsing/selecting recent recordings, and summarizing recordings.
Project: Address more sources of non-determinism
Timelapse can exactly replay executions by making execution deterministic. However, the API available to web applications is large and growing, so Timelapse doesn't handle all sources of nondeterminism. This project would be to address some of these sources with the goal of enabling capture/replay for high-profile websites (Bing, Gmail, Facebook, etc).
A list of known sources of nondeterminism is on the wiki, and there are always open issues pertaining to uncontrolled nondeterminism.
Project: Real-world web benchmark/regression test synthesis
Project: Testing replay, and versioning recordings
Timelapse currently relies on lots of manual testing, which leads to unnoticed regressions. This project would be to build a test harness and other tools necessary to capture/replay a large corpus of saved recordings. Work to be done includes improving recording deserialization support, adding a simple versioning system for recordings, and adding test harness support for loading and replaying recordings. Ideally, we'd set up a Jenkins server or EWS bot for Timelapse.
Project: execution checkpointing via serialization or double-buffering
Timelapse only replays executions forwards in time; backwards movements are achieved by replaying from the beginning and pausing execution earlier. In long recordings, this leads to long seek times. This project would be to investigate ways of checkpointing web app executions so that on average, seek times are reduced. James Lo et. al have published one approach for checkpointing; you could try to replicate this approach, or investigate other approaches. One idea is to keep a few "background" executions paused at intervals throughout the recording; when one of these needs to be used, the foreground execution is swapped with the background execution, akin to double buffering in graphics.
Project: support ENABLE(WEB_REPLAY) for Windows and Linux platforms
Timelapse has only been ported to the OSX platform + Mac port, and can only be used with Safari. This project would be to add necessary support to use Timelapse in other embedders.
Patches/pull requests that add support for other ports within WebKit code, and a patch set that modifies downstream frameworks to use Timelapse APIs and UI where necessary. The GTK port can support usage on Windows, Linux, Mac. WinCairo is another windows port worth targeting.
Project: Remote capture/replay for mobile browsers
Timelapse can capture and replay executions on desktop browsers using WebKit. However, it currently cannot capture/replay executions on mobile devices via remote debugging. It would be really helpful to have this capability because reproducing behaviors on mobile devices can be laborious or impossible.
In particular, importing/exporting Timelapse recordings must work correctly in the case where the frontend host (i.e., developer's desktop) is different from the browser host (i.e., phone browser, remote browser). This project should first focus on iOS as the remote execution host, since that is well-supported already. Other configurations are blocked on upstream support for general remote debugging.