A new key-value API, tentatively `window.crashReport`, backed by a per-Document map holding data that gets appended to crash reports. See https://github.com/WICG/crash-reporting/issues/15 for initial discussion. The data placed in this API's backing map gets sent in the `CrashReportBody` [1] if any renderer process crashes are incurred by the site. This lets developers debug what specific state in their application might be causing a given crash. [1]: https://wicg.github.io/crash-reporting/#crashreportbody
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. The feature https://chromestatus.com/feature/4731248572628992 allows developers to get a JavaScript stack trace, but only for unresponsive crashes. Outside of this narrow case, developers have a hard time tying their specific logic or features to a real-world crash. The `window.crashReport` API exposes a light-weight key-value store that developers can use to store breadcrumbs of their app state, which get appended to crash reports that get sent to their developer-specified endpoints. This significantly helps developers pinpoint the cause of a crash they're seeing in the wild, and radically speed up their debugging cycle.
None
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
None
No milestones specified