Features & functionality

Which data does Bird capture and log?

Last updated on
September 20, 2022

Visual data recording

Tab video recording

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 record the window / full screen. 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.

Replays (DOM mutation recording)

As mentioned on the feature site, the visual part of replays are implemented as DOM recording, 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 video recordings. 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.

System Information recording

The System Information pane shows the following information: TODO

The only known issue in this pane is that the precise MacOS system version is unknown / can’t be differentiated anymore as of 10.15,  because Apple limited the information when freezing the user agent for compatibility reasons (WebKit issue).

Technical data recording

The browser extension records the following technical data types, and allows to enable or disable recording any of them on chrome-extension://mdplmiioglkpgkdblijgilgebpppgblm/options.html:

  • Replay screen recording:
    • Dom mutations
  • Information shown in the Console pane
    • Clicks
    • Script errors
    • Console.debug
    • Console.log
    • Console.info
    • Console.warn
    • Console.error
    • Console.assert
  • Information shown in the
    Network requests
    pane:
    • Network requests
    • Network request responses for
      XMLHttpRequests
      and
      fetch
      requests

Framework/Library Support

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 record offer special recording abilities for state libraries like Redux, and instead focus 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 using iFrames to wrap the main content.

Missing recording capabilities

Most of these items are existing feature requests:

Clicks

Please note that clicks are only recorded if they bubble up to the document.

Network request recording

Network request recording has more caveats than other recorded data types. There are two reasons for that:

  • Frequency and size of network requests
  • Browser APIs allowing to access network request information

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. If Bird would not put reasonable limits in place for network request recording, frequency and size of network events that Bird had to capture would lead to the following issues:

  • Slowdowns of the browser / operating system / recorded pages
  • Running into storage limits
  • Painfully slow session uploads
  • An increased likelihood of Bird or the recorded page crashing

Trade-offs made to prevent these issues:

  • Response bodies are only recorded if their payload size is not more than 1MB.
  • Response bodies are only recorded if the Content-Type header is one including json or text. Bird does not attempt to capture binary information like images, videos, or files like PDFs (which also tend to have larger payload sizes than the mentioned 1MB).

Browser APIs allowing to access network request information

The WebRequest browser extension API does not allow to capture 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 also taken by client-side monitoring tools like Sentry.

Just using the fetch and XMLHttpRequest monkey-patching does not allow to record requests issued by the browser (on page load, form submission,…). Additionally, the WebRequest API runs in a separate browser process, which has less of a performance impact. Lastly, the instrumentation script is only injected into pages with some delay, and might not catch the first requests issued by a page. That’s why Bird employs the WebRequest extension API and in addition instruments fetch and XMLHttpRequest.

Because network requests do not carry a unique identifier that can be used to align the data recorded across the two approaches, Bird merges the information on best-effort-basis using a combination of factors. The algorithm errs on the side of showing less information than recorded instead of implying incorrect relationships between requests and response bodies. Showing the wrong payload as response to a request would mislead developers trying to debug an issue.

So response bodies are only ever recorded for fetch / XMLHttpRequest requests, when matching the rules outlined above in terms of size and content type. Web socket messages are not recorded.

Additionally, response bodies are shown less frequently for GraphQL requests. A reason is that GraphQL requests all call the same endpoint, making it harder to attribute the correct data of the fetch call including the response body to the rest of the request, recorded with the WebRequest API. Secondly, there is a specific issue with the popular Apollo GraphQL client library, where the response body can’t be read.

In conclusion, network requests might not show response bodies for multiple reasons.

See what Bird Eats Bug can do for your team

Try Bird on your next bug - you’ll love it

Try Bird later, from your desktop

See what Bird Eats Bug can do for your team.
By clicking “Accept”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.