1

We are building a web application that sometimes crashes in Mobile Safari due to a jetsam event, where the OS kills the process because of bad memory usage. We think we have a handle on the bug, but some testing shows that it still very occasionally happens, so we want to build some monitoring to gather details on when it happens. Is there a reliable way to detect when the tab crashes that avoids false positives when the tab is closed? Looking at the device logs at the jetsam event, the web process PID (which I believe is just the affected tab since the other tabs were okay) is killed.

Our current plan was to listen to visibilitychange and detect pairs of hidden and visible events, and then count times that we only saw the visible event as a "session crash". However, mobile Safari doesn't seem to comply with the Page Visibility API when a browser tab is closed. We weren't able to see a visibilitychange === hidden event fire on tab close, which would make that scenario look like a crash.

Also considered using a Service Worker to send a heartbeat, but similarly can't think of how to remove false positives of normal tab closes.

  • Sounds like you're on the right track. You should also include terminal telemetry to the SW in response to [`beforeunload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/beforeunload_event) for closes. – jsejcksn Aug 09 '22 at 15:30
  • @jsejcksn, thanks - tried ```beforeunload``` (and ```unload``` and ```pagehide```) too. None of those seem to fire on this tab close scenario. This old StackOverflow question also seems to indicate that ```beforeunload``` doesn't work in Mobile Safari: https://stackoverflow.com/questions/4127621/is-there-any-way-to-use-window-onbeforeunload-on-mobile-safari-for-ios-devices – SidSethupathi Aug 09 '22 at 15:55
  • It seems you're right: I just tested on iOS `15.6` and can verify that's still the case. – jsejcksn Aug 09 '22 at 16:59
  • I can't find any information which suggests that there's a way (using JavaScript) to differentiate a page unload from a crash in mobile Safari, so it seems like you'll have to develop a method of discrimination. Toward that idea: you might consider sending regular, detailed telemetry to the service worker about user interactions and app state. Having this history will help you analyze patterns that could reveal probable crash instances. – jsejcksn Aug 09 '22 at 17:23
  • Hey! I'm dealing with a very similar issue (detecting tab crashes on mobile Safari). Did you find a workaround? I'm pinging a web worker every 500ms and when it crashes the worker won't see the PING so it will send the crash event. It doesn't seem to work though, I think the worker is also killed – pablopunk Mar 07 '23 at 12:16

0 Answers0