v140 · miscellaneous

Crash Reporting key-value API

A new key-value API, tentatively `window.crashReport`, backed by a per-Document map holding data that gets appended to crash reports.

concepts

  1. Crash Key-Value

    Attach key/value metadata to future crash reports. Lets sites tag crashes with the bits they care about (build hash, locale, A/B bucket) without parsing logs after the fact.

  2. Breadcrumb Trail

    The flagship motivation: "breadcrumbs of app state." Walk a fake checkout, then simulate a renderer crash to see the breadcrumb trail and per-step keys appear in the Reporting API payload.

  3. Release Tagging

    Set git_sha, release, and cohort at bootstrap so every future crash from the document can be bucketed by deploy. The single change that lets SRE answer "did the spike start with this push?"

  4. Flag Attribution

    Toggle a panel of feature flags and watch the ff_* keys rewrite in real time. Includes a composite flag_revision key so dashboards can resolve the full set without dumping every flag.

  5. Memory Watermark

    Snapshot heap, DOM node count and active observer count on every navigation so an OOM report arrives with the last good reading. Live gauges with a "grow allocations" stress button.

  6. Worker Breadcrumb Bridge

    Workers can't call crashReporter.set() directly — that API lives only on the main thread's Document. The real pattern is a postMessage bridge: the worker posts structured breadcrumb objects; the main thread stamps them. Simulates a CPU-intensive worker posting incremental progress keys that survive into a crash payload.

why it shipped

The Crash Reporting API (https://wicg.github.io/crash-reporting/) allows developers to know when their site is crashing in the wild, and get some very rudimentary information associated with each crash. But developers don't have enough to go off to debug the crash further.

references