Technical review: Document crash reporting api by chrisdavidmills · Pull Request #43791 · mdn/content

chrisdavidmills · 2026-04-14T15:54:31Z

Description

Chrome 145 adds support for the Crash Reporting API; see https://chromestatus.com/feature/6228675846209536.

I have documented this as part of the Reporting API documentation, rather than in its own API docs tree, as I feel that this makes much sense, even though it is specified in a separate spec.

Motivation

Additional details

Related issues and pull requests

github-actions · 2026-04-14T15:56:07Z

Preview URLs (9 pages)

Flaws (3)

Note! 7 documents with no flaws that don't need to be listed. 🎉

Found an unexpected or unresolvable flaw? Please report it here.

URL: /en-US/docs/Web/API/CrashReportContext
Title: CrashReportContext
Flaw count: 1

macros:
- Macro domxref produces link /en-US/docs/Web/API/fetch which is a redirect

URL: /en-US/docs/Web/API/Window
Title: Window
Flaw count: 2

macros:
- Macro domxref produces link /en-US/docs/Web/API/HTMLElement/invalid_event which is a redirect
- Macro domxref produces link /en-US/docs/Web/API/Element/select_event which is a redirect

External URLs (2)

URL: /en-US/docs/Web/API/CrashReport
Title: CrashReport

https://wicg.github.io/crash-reporting (1 time) (Note! This may be a new URL 👀)

URL: /en-US/docs/Web/API/CrashReportContext
Title: CrashReportContext

https://wicg.github.io/crash-reporting (1 time) (Note! This may be a new URL 👀)

(comment last updated: 2026-04-15 08:00:13)

hamishwillee · 2026-04-14T22:38:15Z

+
+## Instance properties
+
+- `age`


FYI I don't/haven't documented the age and user agent properties - normally I document all the others and then here say "same for server version but also has ...".

Yeah, I know. I did it this way because, in this case, the report type isn't retrieved via reporting observers, so the comparison can't be made.

Works for me. Shouldn't they be alphabetic ordering? I'm "OK "with this being an exception since this is the order it is serialized, but my preference is to do it the same as all other APIs

hamishwillee · 2026-04-14T22:38:52Z

+When the browser crashes, the information stored in the key-value store is added to a {{domxref("CrashReport")}} and sent to the default [reporting server endpoint](/en-US/docs/Web/API/Reporting_API#reporting_server_endpoints), if it is defined. The reporting server endpoint and its mapping to a particular URL are set using the {{httpheader("Reporting-Endpoints")}} header.
+
+> [!NOTE]
+> It is not possible to retrieve {{domxref("CrashReport")}}s using a {{domxref("ReportingObserver")}}.


It is worth saying why, and I would put this as a note up in the description - i.e. this only supports server reports.

Good call; I've updated the note to:

Note
It is not possible to retrieve {{domxref("CrashReport")}}s using a {{domxref("ReportingObserver")}} — the reports are only generated when the browser crashes, at which point the observer code isn't available to run.

I didn't understand the second part of this sentence — the note is in the description already.

The note update is good. I'm suggesting this is important enough to move it below the introductory sentence at the top of the page, rather than here. Mostly because this behaviour is a real outlier for the interface.

jcscottiii

Small nits but LGTM overall

jcscottiii · 2026-04-15T16:51:59Z

+### Basic usage
+
+```js
+window.crashReport.set(1024).then(() => {


nit

Suggested change

window.crashReport.set(1024).then(() => {

window.crashReport.initialize(1024).then(() => {

jcscottiii · 2026-04-15T16:57:21Z

+### Basic usage
+
+```js
+window.crashReport.set(1024).then(() => {


Suggested change

window.crashReport.set(1024).then(() => {

window.crashReport.initialize(1024).then(() => {

jcscottiii · 2026-04-15T16:58:27Z

+### Parameters
+
+- `length`
+  - : A number indicating the maximum number of bytes that can be stored in the key-value store by each individual `set()` call. The maximum allowable value is `5 * 1024 * 1024` (5MB), which is also the maximum amount of crash report memory allowed for one origin.


The limit is actually 64KB

Source: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/public/mojom/frame/frame.mojom;l=261;drc=ad1df7654e8a72f3267dd10890f157ea639b989d

jcscottiii · 2026-04-15T16:58:39Z

+    - The calling document is not fully active.
+    - A crash report key-value store was already initialized by a previous `initialize()` call.
+- `NotAllowedError` {{domxref("DOMException")}}
+  - : `length` is more than `5 * 1024 * 1024`.


See note about updated limit

hamishwillee · 2026-04-17T01:03:30Z

+- `age`
+  - : The age of the report in milliseconds.
+- `type`
+  - : The string `"crash"` indicating that this is a deprecation report.


Suggested change

- : The string `"crash"` indicating that this is a deprecation report.

- : The string `"crash"` indicating that this is a crash report.

hamishwillee · 2026-04-17T01:16:19Z

+
+## Description
+
+The [Crash Reporting API](https://wicg.github.io/crash-reporting) extension to the [Reporting API](/en-US/docs/Web/API/Reporting_API) specifies a mechanism allowing arbitrary information to be recorded and made available in crash reports. This is useful because we can store detailed diagnostic information throughout the lifetime of an application and use the crash reports to debug crashes more effectively.


"The Crash Reporting API extension to the" is unusual. MDN doesn't recognise extensions like this or link direct to spec - that would be added to browser compat or a spec url. For this I would do

Suggested change

The [Crash Reporting API](https://wicg.github.io/crash-reporting) extension to the [Reporting API](/en-US/docs/Web/API/Reporting_API) specifies a mechanism allowing arbitrary information to be recorded and made available in crash reports. This is useful because we can store detailed diagnostic information throughout the lifetime of an application and use the crash reports to debug crashes more effectively.

Crash reports containing arbitrary information can be sent to a server endpoint using the [Reporting API](/en-US/docs/Web/API/Reporting_API) .

This is useful because we can store detailed diagnostic information throughout the lifetime of an application and use the reports to debug crashes more effectively.

hamishwillee · 2026-04-17T01:22:18Z

+
+The [Crash Reporting API](https://wicg.github.io/crash-reporting) extension to the [Reporting API](/en-US/docs/Web/API/Reporting_API) specifies a mechanism allowing arbitrary information to be recorded and made available in crash reports. This is useful because we can store detailed diagnostic information throughout the lifetime of an application and use the crash reports to debug crashes more effectively.
+
+The information is stored in a special key-value store, manipulated using the document's {{domxref("CrashReportContext")}} object, which is accessed via the {{domxref("Window.crashReport")}} property.


Suggested change

The information is stored in a special key-value store, manipulated using the document's {{domxref("CrashReportContext")}} object, which is accessed via the {{domxref("Window.crashReport")}} property.

The diagnostic information is stored in a special key-value store that can be manipulated using the document's {{domxref("CrashReportContext")}} object.

This is accessed via the {{domxref("Window.crashReport")}} property.

hamishwillee · 2026-04-17T01:53:40Z

+
+{{securecontext_header}}{{APIRef("Reporting API")}}
+
+The **`crashReport`** read-only property of the {{domxref("Window")}} interface returns a {{domxref("CrashReportContext")}} object that enables arbitrary data to be recorded for the current top-level browsing context, which is then added to a {{domxref("CrashReport")}} and sent to a reporting endpoint when a browser crash occurs.


Consider making this into shorter sentences.

Suggested change

The **`crashReport`** read-only property of the {{domxref("Window")}} interface returns a {{domxref("CrashReportContext")}} object that enables arbitrary data to be recorded for the current top-level browsing context, which is then added to a {{domxref("CrashReport")}} and sent to a reporting endpoint when a browser crash occurs.

The **`crashReport`** read-only property of the {{domxref("Window")}} interface returns a {{domxref("CrashReportContext")}} object that enables arbitrary data to be recorded for the current top-level browsing context.

The data is then included in {{domxref("CrashReport")}} objects that are sent to a reporting endpoint when a browser crash occurs.

hamishwillee · 2026-04-17T01:54:49Z

+
+## Description
+
+The [Crash Reporting API](https://wicg.github.io/crash-reporting) extension to the [Reporting API](/en-US/docs/Web/API/Reporting_API) specifies a mechanism allowing arbitrary information to be recorded and made available in crash reports. This is useful because we can store detailed diagnostic information throughout the lifetime of an application and use the crash reports to debug crashes more effectively.


Same comment as before - we don't reference specs in page like this.

hamishwillee · 2026-04-17T01:59:06Z

+
+The information is stored in a special key-value store, which is similar to [Web Storage](/en-US/docs/Web/API/Web_Storage_API) except that its scope is restricted to the current top-level origin, and it doesn't have a getter method available. It allows document-specific state information to be recorded and deleted. The top-level document will record diagnostic information relating to it and any embedded documents, and send any related crash reports.
+
+To use this API, a document first needs to call {{domxref("CrashReportContext.initialize", "window.crashReport.initialize()")}}, which takes as an argument a number specifying the maximum number of bytes that can be recorded in the key-value store by each individual {{domxref("CrashReportContext.set", "window.crashReport.set()")}} call. Values are then recorded using `set()`, and deleted using {{domxref("CrashReportContext.delete", "window.crashReport.delete()")}}.


FWIW I was going to say "what happens if you run out of memory when calling set", but this is covered in set()

hamishwillee · 2026-04-17T02:35:02Z

 - {{domxref("IntegrityViolationReport")}}
  - : Contains information about a resource that was blocked because it did not meet the Subresource Integrity guarantees required by its {{httpheader("Integrity-Policy")}}, or that would be blocked for report-only policies set using {{httpheader("Integrity-Policy-Report-Only")}}.
    This is defined as part of the [Subresource Integrity](/en-US/docs/Web/Security/Defenses/Subresource_Integrity) specification.



Add the CrashReport here? I think so.

Document crash reporting api

effe987

chrisdavidmills requested review from a team as code owners April 14, 2026 15:54

chrisdavidmills requested review from hamishwillee and pepelsbey and removed request for a team April 14, 2026 15:54

github-actions bot added the Content:WebAPI Web API docs label Apr 14, 2026

chrisdavidmills changed the title ~~Document crash reporting api~~ Technical review: Document crash reporting api Apr 14, 2026

github-actions bot added the size/m [PR only] 51-500 LoC changed label Apr 14, 2026

hamishwillee reviewed Apr 14, 2026

View reviewed changes

Comment thread files/en-us/web/api/crashreport/index.md Outdated

A few fixes for hamish comments

8410711

jcscottiii reviewed Apr 15, 2026

View reviewed changes

hamishwillee reviewed Apr 17, 2026

View reviewed changes

hamishwillee mentioned this pull request Apr 17, 2026

ReportingAPI: List of reports - draft #43782

Draft

10 tasks

	window.crashReport.set(1024).then(() => {
	window.crashReport.initialize(1024).then(() => {

	- : The string `"crash"` indicating that this is a deprecation report.
	- : The string `"crash"` indicating that this is a crash report.


		## Description

		The [Crash Reporting API](https://wicg.github.io/crash-reporting) extension to the [Reporting API](/en-US/docs/Web/API/Reporting_API) specifies a mechanism allowing arbitrary information to be recorded and made available in crash reports. This is useful because we can store detailed diagnostic information throughout the lifetime of an application and use the crash reports to debug crashes more effectively.

	The [Crash Reporting API](https://wicg.github.io/crash-reporting) extension to the [Reporting API](/en-US/docs/Web/API/Reporting_API) specifies a mechanism allowing arbitrary information to be recorded and made available in crash reports. This is useful because we can store detailed diagnostic information throughout the lifetime of an application and use the crash reports to debug crashes more effectively.
	Crash reports containing arbitrary information can be sent to a server endpoint using the [Reporting API](/en-US/docs/Web/API/Reporting_API) .
	This is useful because we can store detailed diagnostic information throughout the lifetime of an application and use the reports to debug crashes more effectively.


		The [Crash Reporting API](https://wicg.github.io/crash-reporting) extension to the [Reporting API](/en-US/docs/Web/API/Reporting_API) specifies a mechanism allowing arbitrary information to be recorded and made available in crash reports. This is useful because we can store detailed diagnostic information throughout the lifetime of an application and use the crash reports to debug crashes more effectively.

		The information is stored in a special key-value store, manipulated using the document's {{domxref("CrashReportContext")}} object, which is accessed via the {{domxref("Window.crashReport")}} property.

	The information is stored in a special key-value store, manipulated using the document's {{domxref("CrashReportContext")}} object, which is accessed via the {{domxref("Window.crashReport")}} property.
	The diagnostic information is stored in a special key-value store that can be manipulated using the document's {{domxref("CrashReportContext")}} object.
	This is accessed via the {{domxref("Window.crashReport")}} property.


		{{securecontext_header}}{{APIRef("Reporting API")}}

		The `crashReport` read-only property of the {{domxref("Window")}} interface returns a {{domxref("CrashReportContext")}} object that enables arbitrary data to be recorded for the current top-level browsing context, which is then added to a {{domxref("CrashReport")}} and sent to a reporting endpoint when a browser crash occurs.

	The `crashReport` read-only property of the {{domxref("Window")}} interface returns a {{domxref("CrashReportContext")}} object that enables arbitrary data to be recorded for the current top-level browsing context, which is then added to a {{domxref("CrashReport")}} and sent to a reporting endpoint when a browser crash occurs.
	The `crashReport` read-only property of the {{domxref("Window")}} interface returns a {{domxref("CrashReportContext")}} object that enables arbitrary data to be recorded for the current top-level browsing context.
	The data is then included in {{domxref("CrashReport")}} objects that are sent to a reporting endpoint when a browser crash occurs.


		The information is stored in a special key-value store, which is similar to [Web Storage](/en-US/docs/Web/API/Web_Storage_API) except that its scope is restricted to the current top-level origin, and it doesn't have a getter method available. It allows document-specific state information to be recorded and deleted. The top-level document will record diagnostic information relating to it and any embedded documents, and send any related crash reports.

		To use this API, a document first needs to call {{domxref("CrashReportContext.initialize", "window.crashReport.initialize()")}}, which takes as an argument a number specifying the maximum number of bytes that can be recorded in the key-value store by each individual {{domxref("CrashReportContext.set", "window.crashReport.set()")}} call. Values are then recorded using `set()`, and deleted using {{domxref("CrashReportContext.delete", "window.crashReport.delete()")}}.

Conversation

chrisdavidmills commented Apr 14, 2026

Description

Motivation

Additional details

Related issues and pull requests

Uh oh!

github-actions bot commented Apr 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chrisdavidmills Apr 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hamishwillee Apr 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jcscottiii left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hamishwillee Apr 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

github-actions bot commented Apr 14, 2026 •

edited

Loading

chrisdavidmills Apr 15, 2026 •

edited

Loading

hamishwillee Apr 14, 2026 •

edited

Loading

hamishwillee Apr 17, 2026 •

edited

Loading