Crash recovery sets recovered server port to 0, resulting in about:blank page load #248
Comments
|
Update: It seems like the server port isn't passed along to the recovered view: Added logging: Returns:
|
kristfal
changed the title
|
This fix to // don't restart the webserver if we don't have to (fi. after a crash, see #223)
if (_webServer != nil && [_webServer isRunning]) {
int port = [[_webServerOptions objectForKey:@"Port"] intValue]; // Get web server port from options
[myMainViewController setServerPort:port];
return;
}Someone with objC skills should probably review and create a PR. |
|
Update: Despite setting the correct port number, I'm still seeing blank pages on recovery occasionally. The fix above is not fully functional. |
|
great ... i'm looking on it |
|
@kristfal How can you get the WKWebview to crash? |
|
@gregavola I've found two reliable options. They only work on the device: The bad way: Open a lot of other heavy apps after opening your app, then open your app. This usually takes around 20 apps on my iPhone 6. Open too many apps and you will get terminated while running in the background. Too few and your webview won't crash. The less bad way: Open Safari on your Mac and inspect your webview in the debugger. Select the 'Timelines' tab and start recording. Quickly tap around on a few buttons or other places in the app that trigger methods. The app should be non-responsive while recording. Stop recording after around 5-10 seconds. The webview should now crash. If you stop recording too soon, the webview will not crash. If you stop recording too late, the entire app will crash, so try different durations as the duration varies depending on device and number methods called during recording. I have found a very crude workaround for the white screen of death / infinite loading screens. I haven't made a PR because the solution is rather bad as it falls back to crashing the application entirely if it fails to recover properly. Here is the changed code in - (void) applicationDidBecomeActive: (NSNotification*)notification
{
[self performSelector:@selector(recoverFromCrash) withObject:nil afterDelay:0.5];
[self performSelector:@selector(recoverFromCrashFallback) withObject:nil afterDelay:3.5];
}
- (void)recoverFromCrash
{
NSString* title = self.wkWebView.title;
NSLog(@"webview title: %@", title);
if ((title == nil) || [title isEqualToString:@""]) {
(void)self.wkWebView.reload;
}
}
- (void) recoverFromCrashFallback
{
NSString* title = self.wkWebView.title;
NSLog(@"webview title: %@", title);
if ((title == nil) || [title isEqualToString:@""]) {
@throw NSInternalInconsistencyException;
}
}
- (void)webViewWebContentProcessDidTerminate:(WKWebView *)webView
{
(void)self.wkWebView.reload;
}And in the viewDidLoad method, change the crash recovery timer to: // Start timer which periodically checks whether the app is alive
if (![self settingForKey:@"DisableCrashRecovery"] || ![[self settingForKey:@"DisableCrashRecovery"] boolValue]) {
_crashRecoveryTimer = [NSTimer scheduledTimerWithTimeInterval:5 target:self selector:@selector(recoverFromCrashFallback) userInfo:nil repeats:YES];
}In short, this is happening: If the app is running in the foreground, crash recovery is working very well via When the app is returning from the background, it is prone to crashing the webview without calling The periodic timer is the final fallback as we have some times experienced that This solution is acceptable for our production needs, but I wouldn't call it good. Use with caution, and please improve on it if you are able. |
|
@kristfal Thanks for this detail! My biggest concern is that the WKWebview seems to only crash when a ViewControllers is presented above the WKWebView (like Camera view), and the WKWebView Crashes behind the screens, due to poor memory - have you seen this? |
|
@gregavola Not quite sure if I am following. Do you mean that the app is crashing after taking a photo with the Cordova camera plugin? |
|
@kristfal In situations where there is memory pressure - when calling the Camera Plugin, the WKWebview get's placed in the background. Because memory is low, iOS will automatically kill processed in the background (thus killing the WKWebview Pid). This happens whenever the WkWebview is placed in the BG and memory is low. |
|
@gregavola Ah, now I follow. I've seen that happening as well. In that case, with my fix, the webView reloads and recovers without crashing the app. However, the captured photo will not be available. For photo captures, I really recommend to upload the photo to a remote server, and resize it on the server before showing it in the app (do not render the photo directly from a local fileURI). I used to see a lot of crashes with the cordova photo plugin when I attempted to show the photo directly from the captured fileURI. These crashes were resolved when I uploaded the photo first. |
|
@kristfal We don't do any resizing on the app, it's just open Camera, then back to the app and wait for the callback. It seems to kill the PID everytime on some devices. |
|
@kristfal Your last comment - was this an actual crash of camera, or the just restart of the app? |
|
@gregavola That is the webview crashing as it attempts to render the image which was captured by the camera |
|
@kristfal How did you determine that it's the image that crashes the wkwebview? |
Hey,
running version
0.6.9of this plugin, and the performance improvements are great over the regular UIWebView.However, crash recovery seems to be spotty as it occasionally sets the wrong recovery URL.
So, when to forcing a memory warning crash, this happens:
Native Xcode console:
So the crash is detected, the webview is reloading and Cordova is restarting. Great. However, the web-page URL opened after recovery is:
A restart of the app fixes the situation and gives the regular APP url:
Now, the interesting thing is that while being in the
about:blankstate, callinglocation.href = 'http://localhost:12344/index.html';from the safari javascript console loads the correct page and the app continues running after the recovery as expected.I an by no means a comfortable with ObjC, so would really appreciate if someone could look into this.
Related: #223
The text was updated successfully, but these errors were encountered: