Video recordings of a specific tab only include things shown in that tab. Unexpectedly this means that native HTML selects, for which the browser uses native operating system UI, are not visible in tab recordings. Neither are contents of popups. If your recording needs to include interaction with such elements, please select the “record your screen” option. These options also allow to record video outside of the browser, although Bird can’t capture technical information of user interaction with any program outside the browser.
As mentioned on the feature site, the visual part of replays are implemented as DOM recordings, and uses the rrweb library under the hood. The benefit of this technology is that it is - on most pages - a faster and more light-weight alternative to video recording, which is why it can be done continuously in the background and does not need to be started and stopped like our video recording feature. Since this technology is still young there’s still some quirks. Additionally, DOM recording has the fundamental trait that nothing outside the DOM can be recorded. This latter limitation means that only content on the specific page is recorded: Data in popups or other tabs is not recorded, neither is anything outside the HTML document like native MacOS/Windows menus shown for native HTML selects.
On top of that, some embeddable elements like <canvas> are not recorded (e.g. Google Maps, Figma).
When playing back DOM recordings, there can also be visual glitches, like duplicate elements being shown. Even when there’s no obvious glitches, a DOM recording is unlikely to look exactly like the page as experienced by the session reported. Security configuration like CORS on the recorded site’s hosting, and Bird’s own CSP policy can prevent the loading and rendering of embedded elements, like the original page’s font. Because DOM recordings don’t include all information (e.g. image files are only linked to), DOM recordings can drift apart from the time of the recording in fidelity over time, if the content of the asset behind the URL changes, or even degrade, or when the assets are no longer accessible at all at the URL.
To provide a higher level of control, when using the Web SDK, it is possible to customize the rrweb options, as documented here.
The System Information pane shows the following information:
As of MacOS version 10.15, Apple has limited the recording of the precise system version more details here, so Bird is limited to only be able to show that the MacOS version is later than 10.15.7.
The measured values are approximations, since network conditions constantly change, and the connection speed to a server can be quite different from site to site. navigator.connection is used as base information source, but since the download speed measured is capped at 10mbps, Bird downloads a 1MB file from a CDN to gauge a better approximation of the downlink. In areas of the world where the CDN does not host nodes close by, the measurement is likely to be less precise.
The browser extension records a number of technical data types, listed below. You can also enable or disable recording any of them in the extension recording settings page, that can be accessed by copy and pasting this link in a new tab:
chrome-extension://mdplmiioglkpgkdblijgilgebpppgblm/options.html
Replay screen recording
Console pane
* for these console methods, we only record the method call. We are unable to record the output values because these methods depend on context that the extension does not have (e.g. were console groups already opened before the session was started? Were counts already initiated before session recording began?), trigger side-effects we don’t have access to (profiles), or where computing the output would be plausible but imprecise (time method). Hence we decided to show such console method calls only as they happened, without output. Knowing that these methods were called can be helpful to understand the executed code path, and thus help debugging an issue.
Network pane
When React or Vue.js components are logged from one of the mentioned console methods, they are rendered so that they are easy to understand.
The browser extension does not offer special recording abilities for state libraries like Redux, and instead focuses on providing most value independent of a site’s specific tech-stack.
However, we have noticed that technical data recording on AMP pages is prone to missing technical data, due to the use of iFrames to wrap the main content.
Most of these items are existing feature requests:
Please note that only click events that reach the document level are recorded.
Please note that only keydown and input events that reach the document level are recorded.
Network request recording has more caveats than other recorded data types. There are two reasons for that:
Frequency and size of network requests
Pages can execute hundreds or even thousands of network requests per minute. They can contain large payloads. Recording all data flowing over the browser’s network can easily accumulate hundreds of Megabytes of data in short time periods. Therefore we have to put reasonable limits in place for the capture of network request recording, frequency and size of network events, in order to avoid these potential problems:
This does, however, mean making certain trade-offs in the way we record network requests to avoid the aforementioned issues:
Browser APIs allowing to access network request information
The WebRequest browser extension API does not allow the capture of network request responses (at least in Chromium based browsers).
Since response information is likely to contain crucial information for debugging, Bird additionally instruments fetch and XMLHttpRequest, which is the approach taken by client-side monitoring tools such as Sentry.
Just using the fetch and XMLHttpRequest monkey-patching does not allow to record requests issued by the browser (on page load, form submission,…). For this reason, Bird employs the WebRequest extension API for all request types except for fetch and XMLHttpRequest, and instead records these by instrumenting fetch and XMLHttpRequest. Due to the different data sources, the timing / order of requests can potentially slightly differ from the actual timing / order.
Web socket messages are currently not recorded.
In conclusion, while we are constantly making improvements on the recording of network requests, due to reasons outlined above, there will sometimes be instances where response bodies are not shown.
Try Bird on your next bug - you’ll love it
“Game changer”
Julie, Head of QA
Try Bird later, from your desktop