capacitor: feat: Notify JS-layer when webview crashed

Feature Request

It would be great if the JS-layer (Capacitor app) could know that the underlying web view crashed and subsequently restarted. Right now there is nothing to discern these from a regular app startup and users won’t be aware that data was lost.

More concretely, an issue that occur frequently is that we take a photograph via an <input capture> element and do on-the-fly resize using JS and canvas, and the web view crashes, causing the page to reload. But for the user this isn’t obvious, it’s just a short flash when the web view reloads, and they don’t know that the photograph failed and they’ve just lost data.

If we could listen to these events we could show a warning to the user.

This is the code on iOS today:

https://github.com/ionic-team/capacitor/blob/0a25cce21f935c0d18cdeb9b0e04a9b6145f2072/ios/Capacitor/Capacitor/CAPBridgeViewController.swift#L279-L281

Platform Support Requested

Android
iOS

Describe Preferred Solution

There are multiple solutions, but one could be a listener similar to appRestoredResult , that would let us know that the app restored after a crash.

We’d then have the ability to show a warning to the user.

Additional Context

This related issue about the web view crashing when taking photos: https://github.com/ionic-team/capacitor/issues/2265

About this issue

Original URL
State: open
Created 4 years ago
Reactions: 16
Comments: 18 (9 by maintainers)

Most upvoted comments

We have found the iOS WebView to be very sensitive to memory usage. It crashes quite often on startup, possibly due to this bug: https://bugs.webkit.org/show_bug.cgi?id=212790. If you have any memory leaks in the WebView, it will eventually be terminated. WebKit unfortunately has some nasty memory leaks associated with the <video> and <canvas> elements.

In general, an automatic reload is necessary in production. But I would prefer a crash in development. And ideally, we should be able to override the default behaviour, so we can maintain the integrity of the app.

diachedelic on Jan 28, 2022

Just another though – silently restarting the webview can leave plugins in an inconsistent state. For example, if you have called Geolocation.watchPosition, and the webview crashes and reloads, there is no way to halt location updates other than manually killing and restarting the app.

I have been running Capacitor in development with the below modification for months now, and I would love to see this behaviour behind a configuration option.

diff --git a/CAPBridgeViewController.swift b/CAPBridgeViewController.swift
index 431c46ae..fb1c8bdd 100644
--- a/CAPBridgeViewController.swift
+++ b/CAPBridgeViewController.swift
@@ -344,7 +344,7 @@ public class CAPBridgeViewController: UIViewController, CAPBridgeDelegate, WKScr
   }
 
   public func webViewWebContentProcessDidTerminate(_ webView: WKWebView) {
-    webView.reload()
+    fatalError("webViewWebContentProcessDidTerminate")
   }

diachedelic on Nov 23, 2020

Would it be so crazy to crash the app if webViewWebContentProcessDidTerminate was called? I think I would prefer the app to quit immediately and obviously, rather than data disappearing silently. Perhaps it could be a configuration option.

diachedelic on Aug 20, 2020

@jcesarmobile Yeah, I looked at that event too, but seems like it has slightly different semantics/meaning. It’s more of a switching thing.

Maybe a separate event for crashes would make more sense, e.g. restartedAfterCrash or similar.

sandstrom on Jan 29, 2020