Adding support for additional context / dimensions in the crash report

WICG / crash-reporting

Crash reporting (from Web Perf WG)

https://wicg.github.io/crash-reporting/

Other

8 stars 7 forks source link

Adding support for additional context / dimensions in the crash report #14

Open nicholaschen opened 4 months ago

nicholaschen commented 4 months ago

The current web reporting payload contains context from the client at time of the crash. additional contextual information would help with debugging, primarily:

If the tab / app was in the foreground at time of crash

Other nice-to-have context information:

A signal for the amount of memory in use before the crash occurred
The last known JS/WASM/Chrome execution frame
How many other pages shared this process? (i.e. Is it possible that another page caused the crash? Or was it a shared worker process?)

clelland commented 4 months ago

I think that background/foreground status is certainly possible. JS stack traces are being tracked in #12, and should at least be included in "unresponsive" reports.

Memory and number-of-shared-pages may have privacy issues, and I'm not sure that we can include those. Especially for browsers without full site/process isolation, this could easily leak information about a user's activity on unrelated websites.

clelland commented 3 days ago

I think that the best signal for background/foreground would be the document's visibility state, so we could add a "visibilityState" key, with values "visible" or "hidden" to the reports.

clelland commented 3 days ago

The problem with exposing the number of documents / pages which shared this crash is that it exposes additional information about the users browsing session beyond what was happening in the specific page which configured reporting. In browsers without origin isolation, this can expose the presence of pages on other origins which shared the process, and even with site- or origin isolation, may expose more than would normally be available to the page (notwithstanding the existence of meltdown-style memory attacks)

It might be the case that with COOP/COEP isolation, a page would be able to tell how many other frames share its process even before a crash, and so we wouldn't be exposing anything new to report that during a crash. I'll have to see if I can verify that though.