Crash recovery implementation should be removed / is harmful.
lolsborn opened this issue · comments
The crash recovery code was causing us some headaches and 'recovering' our app quite a bit without explanation and it seemed to be happening when switching views, but really hard to reproduce.
It didn't take but a few seconds of looking at the code to realize that it is completely bonkers.
// When an empty title is returned, WkWebView has crashed
NSString* title = self.wkWebView.title;
if ((title == nil) || [title isEqualToString:@""]) {
So an empty title is an indicator of a crash!?
Most Cordova apps are single page applications and often times the title is a dynamic element. All you need to do to reproduce this bug is:
document.title = "";
To make things worse the code isn't just checking on page load or something, but based on a timer. It's can be triggered randomly as a race condition...
_crashRecoveryTimer = [NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(recoverFromCrash) userInfo:nil repeats:YES];
LOL WUT
This code is so bad and should not be included in the plugin at all. Having an option to disable it is not good enough because it is broken by default.
Awesome comment. Any suggestions on how to detect a crash in a better way?
I honestly don't know what problems this code was meant to solve. If a web app is crashing for some reason it should probably be fixed instead of washed over with some sort of watch-dog timer. Is there some particular use-case that this fixes or is it just a crutch for poorly written apps?
To keep it DRY please see #62 and you're very welcome to think of a better solution.
Just to make sure you didn't miss this: at the Take note! section in the readme it's mentioned how crash recovery can be disabled and what you need to do to have it behave as intended. Dynamically updating the title is not something the author of the crash recovery mechanism anticipated someone would need to do in a Cordova app.
I'm not sure what the best way to detect a crash, but right now the trade off we have by turning this on by default is that it is useful for a small set of apps that have what appears to be a memory leak based on the reference app, in exchange the plugin introduces a race condition causing crashes in single page apps using Ionic, Sencha, Angular, etc.
In Ionic/Angular the html is rendered in JS so that you start off with something like. Where variable is some reference in javascript.
<title>{{ variable }}</title>
Is pretty common and updated based on the current view. That variable might be null/undefined at the time the view loads and populated in javascript based on the content viewed. Say for instance you were viewing a contact, you might set the view title to customer.name on a new record this might be blank and cause a crash. If you set it to null initially and then load in the customer info via XHR it can cause a crash.
I'm aware it can be turned off, but I don't think the trade-off here is defensible since it is likely to cause more harm than good. I would suggest that the default state be off unless a better solution can be found because anyone using this feature should really understand the tradeoffs involved.
What I don't get is why you'd want to change the title tag at all. That's probably also what the author of the crash detection mechanism though would not be relevant in a mobile app.
So if you consider that for a second I hope you can also appreciate it's not the nicest remark to just say something is completely bonkers.
As long as no one has a decent way of reproducing the crash I will not change the default since I know the crashes have caused a lot of trouble in the past where all of a sudden the app would simply show a blank screen because iOS thought it would be a good idea to kill the WKWebView thread.
As with all OSS projects: fork it if you don't like it. And if you think your fork is better send a PR upstream and have a friendly discussion.
Here is a really common Ionic app with a side-menu. Any Ionic app using the side-menu template will work like this. When you change between the view between Browse, Search, Playlist it changes the title.
Changing the route changes the "visible" title indeed (screenshot of the <h1> header of that plunker):
But that's not the element the recovery system looks for - that's the <title> tag in the head which isn't used in mobile apps and should be made non-empty when using the recovery system (screenshot of inspected code of that plunker):
