search

WICG / crash-reporting

Crash reporting (from Web Perf WG)
https://wicg.github.io/crash-reporting/
Other
8 stars 7 forks source link

Expose more qualitative data #7

Open annevk opened 4 years ago

annevk commented 4 years ago

If we require UI as per #1 this might open the door to exposing more qualitative data. Does that seem reasonable, desirable?

cc @vdjeric @pes10k

pes10k commented 4 years ago

If there was affirmative opt-in UI, to ensure users were actively and intentionally sending the data, that seems both reasonable and desirable to me

vdjeric commented 4 years ago

What kind of qualitative data are you thinking of? I guess it would be a tradeoff between reliable metrics vs data that helps debug the crash, but I don't know what qualitative data would be helpful for debugging crashes, can you elaborate? C++ stacks?

annevk commented 4 years ago

This is an example of the kind of crash reports Firefox gets: https://crash-stats.mozilla.org/report/index/27791016-fd8a-43a0-a8a6-095a30200421. Process isolation might have to be further along to offer this though, not sure.

arenevier commented 4 years ago

We (at facebook) would have limited use for those informations. We don't need to know all those hardware characteristics, and the only reason why we would want a stack trace would be if we work with the browser vendors to fix an issue. But in that case, I guess we would already have access to that information via their native crash reporter.

We are more interested in informations such as: is this URL causing out of memory crashes in the real world? If so, for which percentage of users, and with which browser?