Skip to content

Introduce the CrashReportStorage interface #37

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: gh-pages
Choose a base branch
from

Conversation

domfarolino
Copy link
Collaborator

@domfarolino domfarolino commented Jul 30, 2025

aarongable pushed a commit to chromium/chromium that referenced this pull request Aug 1, 2025
This CL addresses
WICG/crash-reporting#37 (comment),
by nesting all of the crash report storage values provided by the
`CrashReportStorage` object in Blink, under the "crash_report_api" key,
so that they cannot clash with the more "privileged" keys/values that
the browser adds on its own, that should not be over-writable by
developer input.

Before this change, if you used the CrashReportStorage API to add
context to crash reports, the report would look something like:

{
  "is_top_level" : "true",
  ...,
  "custom_key"   : "custom_value",
  "custom_key_2" : "custom_value_2",
}

After this change, the reports look like:

{
  "is_top_level"  : "true",
  ...,
  "crash_report_api": {
    "custom_key"   : "custom_value",
    "custom_key_2" : "custom_value_2",
  }
}

R=creis, mmenke

Bug: 400432195
Change-Id: I382f30c924aaf112bc4133fde56156aa7f769d52
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6811940
Commit-Queue: Dominic Farolino <[email protected]>
Reviewed-by: mmenke <[email protected]>
Reviewed-by: Arthur Sonzogni <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1495483}
@domfarolino domfarolino changed the title Introduce the CrashReportStorage object Introduce the CrashReportStorage interface Aug 1, 2025
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Aug 6, 2025
This CL introduces the `initialize()` method to the `CrashReportStorage`
interface, introduced in [1] and [2]. This API gives an asynchronous gap
for the implementation to initialize any relevant backing memory for the
crash report storage.

In the current Chromium implementation, this isn't used since the web
APIs `set()` and `remove()` are backed by synchronous IPCs, but this
method is required by the spec proposal to allow for more sophisticated
mechanisms to be used for the backing memory. In Chromium, we are
exploring taking advantage of this in https://crrev.com/c/6788146, where
we're considering replacing `RenderFrameHostImpl::crash_storage_map_`
with a shared memory region that spans the browser and renderer process.

[1]:
https://github.com/WICG/crash-reporting/blob/gh-pages/crashReport-explainer.md
[2]: WICG/crash-reporting#37

R=creis, dcheng

Bug: 400432195
Change-Id: I7ee67d29c6d4601b4d7ecb2d0b54dd24d0111e39
aarongable pushed a commit to chromium/chromium that referenced this pull request Aug 6, 2025
This CL introduces the `initialize()` method to the `CrashReportStorage`
interface, introduced in [1] and [2]. This API gives an asynchronous gap
for the implementation to initialize any relevant backing memory for the
crash report storage.

In the current Chromium implementation, this isn't used since the web
APIs `set()` and `remove()` are backed by synchronous IPCs, but this
method is required by the spec proposal to allow for more sophisticated
mechanisms to be used for the backing memory. In Chromium, we are
exploring taking advantage of this in https://crrev.com/c/6788146, where
we're considering replacing `RenderFrameHostImpl::crash_storage_map_`
with a shared memory region that spans the browser and renderer process.

[1]:
https://github.com/WICG/crash-reporting/blob/gh-pages/crashReport-explainer.md
[2]: WICG/crash-reporting#37

R=creis, dcheng

Bug: 400432195
Change-Id: I7ee67d29c6d4601b4d7ecb2d0b54dd24d0111e39
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6819100
Reviewed-by: Steven Holte <[email protected]>
Commit-Queue: Dominic Farolino <[email protected]>
Reviewed-by: Daniel Cheng <[email protected]>
Reviewed-by: mmenke <[email protected]>
Reviewed-by: Charlie Reis <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1497721}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Aug 6, 2025
This CL introduces the `initialize()` method to the `CrashReportStorage`
interface, introduced in [1] and [2]. This API gives an asynchronous gap
for the implementation to initialize any relevant backing memory for the
crash report storage.

In the current Chromium implementation, this isn't used since the web
APIs `set()` and `remove()` are backed by synchronous IPCs, but this
method is required by the spec proposal to allow for more sophisticated
mechanisms to be used for the backing memory. In Chromium, we are
exploring taking advantage of this in https://crrev.com/c/6788146, where
we're considering replacing `RenderFrameHostImpl::crash_storage_map_`
with a shared memory region that spans the browser and renderer process.

[1]:
https://github.com/WICG/crash-reporting/blob/gh-pages/crashReport-explainer.md
[2]: WICG/crash-reporting#37

R=creis, dcheng

Bug: 400432195
Change-Id: I7ee67d29c6d4601b4d7ecb2d0b54dd24d0111e39
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6819100
Reviewed-by: Steven Holte <[email protected]>
Commit-Queue: Dominic Farolino <[email protected]>
Reviewed-by: Daniel Cheng <[email protected]>
Reviewed-by: mmenke <[email protected]>
Reviewed-by: Charlie Reis <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1497721}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Aug 6, 2025
This CL introduces the `initialize()` method to the `CrashReportStorage`
interface, introduced in [1] and [2]. This API gives an asynchronous gap
for the implementation to initialize any relevant backing memory for the
crash report storage.

In the current Chromium implementation, this isn't used since the web
APIs `set()` and `remove()` are backed by synchronous IPCs, but this
method is required by the spec proposal to allow for more sophisticated
mechanisms to be used for the backing memory. In Chromium, we are
exploring taking advantage of this in https://crrev.com/c/6788146, where
we're considering replacing `RenderFrameHostImpl::crash_storage_map_`
with a shared memory region that spans the browser and renderer process.

[1]:
https://github.com/WICG/crash-reporting/blob/gh-pages/crashReport-explainer.md
[2]: WICG/crash-reporting#37

R=creis, dcheng

Bug: 400432195
Change-Id: I7ee67d29c6d4601b4d7ecb2d0b54dd24d0111e39
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6819100
Reviewed-by: Steven Holte <[email protected]>
Commit-Queue: Dominic Farolino <[email protected]>
Reviewed-by: Daniel Cheng <[email protected]>
Reviewed-by: mmenke <[email protected]>
Reviewed-by: Charlie Reis <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1497721}
mohamedamir pushed a commit to mohamedamir/wpt that referenced this pull request Aug 7, 2025
This CL introduces the `initialize()` method to the `CrashReportStorage`
interface, introduced in [1] and [2]. This API gives an asynchronous gap
for the implementation to initialize any relevant backing memory for the
crash report storage.

In the current Chromium implementation, this isn't used since the web
APIs `set()` and `remove()` are backed by synchronous IPCs, but this
method is required by the spec proposal to allow for more sophisticated
mechanisms to be used for the backing memory. In Chromium, we are
exploring taking advantage of this in https://crrev.com/c/6788146, where
we're considering replacing `RenderFrameHostImpl::crash_storage_map_`
with a shared memory region that spans the browser and renderer process.

[1]:
https://github.com/WICG/crash-reporting/blob/gh-pages/crashReport-explainer.md
[2]: WICG/crash-reporting#37

R=creis, dcheng

Bug: 400432195
Change-Id: I7ee67d29c6d4601b4d7ecb2d0b54dd24d0111e39
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6819100
Reviewed-by: Steven Holte <[email protected]>
Commit-Queue: Dominic Farolino <[email protected]>
Reviewed-by: Daniel Cheng <[email protected]>
Reviewed-by: mmenke <[email protected]>
Reviewed-by: Charlie Reis <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1497721}
lando-prod-mozilla bot pushed a commit to mozilla-firefox/firefox that referenced this pull request Aug 8, 2025
…eportStorage, a=testonly

Automatic update from web-platform-tests
Crash: Add initialize() method to CrashReportStorage

This CL introduces the `initialize()` method to the `CrashReportStorage`
interface, introduced in [1] and [2]. This API gives an asynchronous gap
for the implementation to initialize any relevant backing memory for the
crash report storage.

In the current Chromium implementation, this isn't used since the web
APIs `set()` and `remove()` are backed by synchronous IPCs, but this
method is required by the spec proposal to allow for more sophisticated
mechanisms to be used for the backing memory. In Chromium, we are
exploring taking advantage of this in https://crrev.com/c/6788146, where
we're considering replacing `RenderFrameHostImpl::crash_storage_map_`
with a shared memory region that spans the browser and renderer process.

[1]:
https://github.com/WICG/crash-reporting/blob/gh-pages/crashReport-explainer.md
[2]: WICG/crash-reporting#37

R=creis, dcheng

Bug: 400432195
Change-Id: I7ee67d29c6d4601b4d7ecb2d0b54dd24d0111e39
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6819100
Reviewed-by: Steven Holte <[email protected]>
Commit-Queue: Dominic Farolino <[email protected]>
Reviewed-by: Daniel Cheng <[email protected]>
Reviewed-by: mmenke <[email protected]>
Reviewed-by: Charlie Reis <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1497721}

--

wpt-commits: 50a4d0664f7b473db8998b06fed35769bda66774
wpt-pr: 54174
aarongable pushed a commit to chromium/chromium that referenced this pull request Aug 12, 2025
This CL introduces the `initialize()` method to the `CrashReportStorage`
interface, introduced in [1] and [2]. This API gives an asynchronous gap
for the implementation to initialize any relevant backing memory for the
crash report storage.

In the current Chromium implementation, this isn't used since the web
APIs `set()` and `remove()` are backed by synchronous IPCs, but this
method is required by the spec proposal to allow for more sophisticated
mechanisms to be used for the backing memory. In Chromium, we are
exploring taking advantage of this in https://crrev.com/c/6788146, where
we're considering replacing `RenderFrameHostImpl::crash_storage_map_`
with a shared memory region that spans the browser and renderer process.

[1]:
https://github.com/WICG/crash-reporting/blob/gh-pages/crashReport-explainer.md
[2]: WICG/crash-reporting#37

R=creis, dcheng

(cherry picked from commit 5a6019f)

Bug: 400432195
Change-Id: I7ee67d29c6d4601b4d7ecb2d0b54dd24d0111e39
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6819100
Reviewed-by: Steven Holte <[email protected]>
Commit-Queue: Dominic Farolino <[email protected]>
Reviewed-by: Daniel Cheng <[email protected]>
Reviewed-by: mmenke <[email protected]>
Reviewed-by: Charlie Reis <[email protected]>
Cr-Original-Commit-Position: refs/heads/main@{#1497721}
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6829444
Reviewed-by: Alex Moshchuk <[email protected]>
Cr-Commit-Position: refs/branch-heads/7339@{#410}
Cr-Branched-From: 27be8b7-refs/heads/main@{#1496484}
foolip pushed a commit to web-platform-tests/wpt that referenced this pull request Aug 13, 2025
This CL introduces the `initialize()` method to the `CrashReportStorage`
interface, introduced in [1] and [2]. This API gives an asynchronous gap
for the implementation to initialize any relevant backing memory for the
crash report storage.

In the current Chromium implementation, this isn't used since the web
APIs `set()` and `remove()` are backed by synchronous IPCs, but this
method is required by the spec proposal to allow for more sophisticated
mechanisms to be used for the backing memory. In Chromium, we are
exploring taking advantage of this in https://crrev.com/c/6788146, where
we're considering replacing `RenderFrameHostImpl::crash_storage_map_`
with a shared memory region that spans the browser and renderer process.

[1]:
https://github.com/WICG/crash-reporting/blob/gh-pages/crashReport-explainer.md
[2]: WICG/crash-reporting#37

R=creis, dcheng

Bug: 400432195
Change-Id: I7ee67d29c6d4601b4d7ecb2d0b54dd24d0111e39
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6819100
Reviewed-by: Steven Holte <[email protected]>
Commit-Queue: Dominic Farolino <[email protected]>
Reviewed-by: Daniel Cheng <[email protected]>
Reviewed-by: mmenke <[email protected]>
Reviewed-by: Charlie Reis <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1497721}
i3roly pushed a commit to i3roly/firefox-dynasty that referenced this pull request Aug 14, 2025
…eportStorage, a=testonly

Automatic update from web-platform-tests
Crash: Add initialize() method to CrashReportStorage

This CL introduces the `initialize()` method to the `CrashReportStorage`
interface, introduced in [1] and [2]. This API gives an asynchronous gap
for the implementation to initialize any relevant backing memory for the
crash report storage.

In the current Chromium implementation, this isn't used since the web
APIs `set()` and `remove()` are backed by synchronous IPCs, but this
method is required by the spec proposal to allow for more sophisticated
mechanisms to be used for the backing memory. In Chromium, we are
exploring taking advantage of this in https://crrev.com/c/6788146, where
we're considering replacing `RenderFrameHostImpl::crash_storage_map_`
with a shared memory region that spans the browser and renderer process.

[1]:
https://github.com/WICG/crash-reporting/blob/gh-pages/crashReport-explainer.md
[2]: WICG/crash-reporting#37

R=creis, dcheng

Bug: 400432195
Change-Id: I7ee67d29c6d4601b4d7ecb2d0b54dd24d0111e39
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6819100
Reviewed-by: Steven Holte <[email protected]>
Commit-Queue: Dominic Farolino <[email protected]>
Reviewed-by: Daniel Cheng <[email protected]>
Reviewed-by: mmenke <[email protected]>
Reviewed-by: Charlie Reis <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1497721}

--

wpt-commits: 50a4d0664f7b473db8998b06fed35769bda66774
wpt-pr: 54174
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this pull request Aug 16, 2025
…eportStorage, a=testonly

Automatic update from web-platform-tests
Crash: Add initialize() method to CrashReportStorage

This CL introduces the `initialize()` method to the `CrashReportStorage`
interface, introduced in [1] and [2]. This API gives an asynchronous gap
for the implementation to initialize any relevant backing memory for the
crash report storage.

In the current Chromium implementation, this isn't used since the web
APIs `set()` and `remove()` are backed by synchronous IPCs, but this
method is required by the spec proposal to allow for more sophisticated
mechanisms to be used for the backing memory. In Chromium, we are
exploring taking advantage of this in https://crrev.com/c/6788146, where
we're considering replacing `RenderFrameHostImpl::crash_storage_map_`
with a shared memory region that spans the browser and renderer process.

[1]:
https://github.com/WICG/crash-reporting/blob/gh-pages/crashReport-explainer.md
[2]: WICG/crash-reporting#37

R=creis, dcheng

Bug: 400432195
Change-Id: I7ee67d29c6d4601b4d7ecb2d0b54dd24d0111e39
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6819100
Reviewed-by: Steven Holte <holtechromium.org>
Commit-Queue: Dominic Farolino <domchromium.org>
Reviewed-by: Daniel Cheng <dchengchromium.org>
Reviewed-by: mmenke <mmenkechromium.org>
Reviewed-by: Charlie Reis <creischromium.org>
Cr-Commit-Position: refs/heads/main{#1497721}

--

wpt-commits: 50a4d0664f7b473db8998b06fed35769bda66774
wpt-pr: 54174

UltraBlame original commit: a8c0b56d143c68a5551c0f14ad2e8f0330639510
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this pull request Aug 16, 2025
…eportStorage, a=testonly

Automatic update from web-platform-tests
Crash: Add initialize() method to CrashReportStorage

This CL introduces the `initialize()` method to the `CrashReportStorage`
interface, introduced in [1] and [2]. This API gives an asynchronous gap
for the implementation to initialize any relevant backing memory for the
crash report storage.

In the current Chromium implementation, this isn't used since the web
APIs `set()` and `remove()` are backed by synchronous IPCs, but this
method is required by the spec proposal to allow for more sophisticated
mechanisms to be used for the backing memory. In Chromium, we are
exploring taking advantage of this in https://crrev.com/c/6788146, where
we're considering replacing `RenderFrameHostImpl::crash_storage_map_`
with a shared memory region that spans the browser and renderer process.

[1]:
https://github.com/WICG/crash-reporting/blob/gh-pages/crashReport-explainer.md
[2]: WICG/crash-reporting#37

R=creis, dcheng

Bug: 400432195
Change-Id: I7ee67d29c6d4601b4d7ecb2d0b54dd24d0111e39
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6819100
Reviewed-by: Steven Holte <holtechromium.org>
Commit-Queue: Dominic Farolino <domchromium.org>
Reviewed-by: Daniel Cheng <dchengchromium.org>
Reviewed-by: mmenke <mmenkechromium.org>
Reviewed-by: Charlie Reis <creischromium.org>
Cr-Commit-Position: refs/heads/main{#1497721}

--

wpt-commits: 50a4d0664f7b473db8998b06fed35769bda66774
wpt-pr: 54174

UltraBlame original commit: a8c0b56d143c68a5551c0f14ad2e8f0330639510
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this pull request Aug 16, 2025
…eportStorage, a=testonly

Automatic update from web-platform-tests
Crash: Add initialize() method to CrashReportStorage

This CL introduces the `initialize()` method to the `CrashReportStorage`
interface, introduced in [1] and [2]. This API gives an asynchronous gap
for the implementation to initialize any relevant backing memory for the
crash report storage.

In the current Chromium implementation, this isn't used since the web
APIs `set()` and `remove()` are backed by synchronous IPCs, but this
method is required by the spec proposal to allow for more sophisticated
mechanisms to be used for the backing memory. In Chromium, we are
exploring taking advantage of this in https://crrev.com/c/6788146, where
we're considering replacing `RenderFrameHostImpl::crash_storage_map_`
with a shared memory region that spans the browser and renderer process.

[1]:
https://github.com/WICG/crash-reporting/blob/gh-pages/crashReport-explainer.md
[2]: WICG/crash-reporting#37

R=creis, dcheng

Bug: 400432195
Change-Id: I7ee67d29c6d4601b4d7ecb2d0b54dd24d0111e39
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6819100
Reviewed-by: Steven Holte <holtechromium.org>
Commit-Queue: Dominic Farolino <domchromium.org>
Reviewed-by: Daniel Cheng <dchengchromium.org>
Reviewed-by: mmenke <mmenkechromium.org>
Reviewed-by: Charlie Reis <creischromium.org>
Cr-Commit-Position: refs/heads/main{#1497721}

--

wpt-commits: 50a4d0664f7b473db8998b06fed35769bda66774
wpt-pr: 54174

UltraBlame original commit: a8c0b56d143c68a5551c0f14ad2e8f0330639510
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants