clelland
commented
3 months ago It makes sense to me that data which was available to the site immediately before the crash could be useful, and could have been beaconed in any case / pushState'd into the crashing URL. This provides an ergonomic way of attaching relevant data to the report.
A question would be whether this makes sense for the Reporting API in general (separate from the report body), or if it should be part of Crash reports specifically (and be in the report body)
The web reporting API exposes a single entry-point for setting additional context for any crash reports i.e. the initial load URI and the Reporting-Endpoints header. To propagate any client context, an implementation needs to append additional params to the URL, and the server-endpoint needs to implement logic to correctly parse it. This works well for in cases where the context can be inferred on initial load, however, this isn't necessarily true of all apps, since some apps could choose to load a static "app shell" with content loaded dynamically.
It would be nice if there was a way to add app context programmatically while the app is executing to get insight into what the app was doing that may have triggered a crash, deprecation, or intervention.
Impact: By exposing a client-level entry-point to specify context to the web reporting message, products can provide their own implementation + add context closer to the time of crash, offering insight into crash scenarios not caused by the initial load, but through specific user-interactions.
JS API Ideas:
Ideal: Allow JS to append a JSON metadata object onto the top-level report.idl definition [1]. Allow JS to update the Reporting-Endpoints URL during execution.
[1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/frame/report.idl;l=9-14;drc=292435cd87cf428066d403e78df42fa237cc374b