Adding support for additional context / dimensions in the crash report

[nicholaschen]

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]

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]

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]

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.

[aluhrs13]

If we were to do #15, many of these might be reasonable for us to skip and let the page do it itself if that's relevant? For instance, if visibility is something that's relevant to my app's state, I could call the JS API in my app's visibilitychange handler.

Document count wouldn't be possible to get that way, so probably would need to be special-cased (or add an API for that instead of adding it here?)

Memory is an interesting middle ground since there's no event on major changes. Polling measureUserAgentSpecificMemory periodically probably isn't the best thing for us to recommend.