I imagine this has probably been discussed before, but I can’t find it. Is anybody aware of prior art in this area? In short, I’d like a way to report the stack trace at the time when the browser decides that a webpage has become unresponsive.
Problem description
With window.onerror, we have an excellent tool for reporting JavaScript exceptions that occur on customer machines. On the last web site I worked on, we discovered and fixed many bugs thanks to reports uploaded by a window.onerror handler. However, there are two other categories of catastrophic failure that never showed up in our server-side logs: out-of-memory crashes (a hard problem I won’t attempt to address here) and code that just ran for a really long time. Browsers detect when a page has become unresponsive and they put up a dialog asking whether to terminate the page, but script on the page has no way to respond to this condition.
API options
I could imagine a couple of different designs for this API; there are probably more options not covered here.
- The declarative approach: Sometime during page setup, script code calls a function
sendBeaconOnHangand specifies the URL where hang reports should go, along with any additional data (such as session ID) that should be included. If the browser detects a page hang and decides to put up the unresponsive-page dialog, it also sends a hang report to the specified URL. The format of the hang report is standardized and includes the current JS call stack. Of course some details in the call stack may be omitted subject to CORS restrictions, just like for any other features that include call stacks. - The procedural approach: Sometime during page setup, script code registers a callback function which will get invoked during a hang. If the browser detects a page hang, it will interrupt running script and synchronously call the callback. The callback can use the current call stack (
new Error().stackor similar) for reporting. This option provides more flexibility at the cost of higher complexity.