-
Notifications
You must be signed in to change notification settings - Fork 8
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
domfarolino
wants to merge
5
commits into
gh-pages
Choose a base branch
from
domfarolino/CrashReportStorage-object
base: gh-pages
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
domenic
reviewed
Jul 31, 2025
4 tasks
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}
CrashReportStorage
objectCrashReportStorage
interface
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Explainer: https://github.com/WICG/crash-reporting/blob/gh-pages/crashReport-explainer.md.
See also: https://chromestatus.com/feature/6228675846209536.