Could we expose browser crashes to developers? #29
Description
(discussed at TPAC 2016; rough notes and summary of discussed ideas below)
Despite our best efforts, browser crashes are a thing.. with out-of-memory being one of the most common (but not the only) culprits. Anecdotally, this is particularly bad on lower end devices that don't have a lot of memory: some sites go to great lengths to detect such devices and aggressively remove/downsize their images/video, etc, to ensure that the user is able to view the page. It would be nice if the browser provided a feedback mechanism to detect such cases.
Anecdotally, some sites are already attempting to track "crashes" by setting a localStorage flag when the page opens, and toggling it to off when visibilityState changes.. If the page is loaded and this flag is set, it means that the previous navigation did not "end cleanly" -- this doesn't explain what the problem was, but even a baseline metric of "problem exists" is a useful signal.
Question: is there anything we (webperf group) could or should do to help identify these cases?
- The first obvious problem is that the browser is often not in a much better place to detect or explain why a crash happened -- e.g. we may be able to detect that a crash happened, but if the OS decided to brute-kill a process, there is little we can do to know why it did so. However, perhaps even a simple "your page was killed" report might be a significant and helpful signal to developers.
- Are there privacy/security implications of exposing browser crashes? If we could extract some meaningful reason for the crash, would we be able to expose it?
Also, at least in theory, Reporting API already provides the necessary infrastructure to queue the out-of-band report. What we'd have to define is how/when such reports are triggered.