iOS 12, Web View reloads, possibly when using high amount of resources.

[simonwatt]

cli-8.1.1 (iOS 4.5.5) cordova-plugin-ionic-webview 4.0.0 Built with PhoneGap Build

Ever since iOS 12 (up to 12.2) my Apps users have been reporting random crashes, either white screens or the App attempting to reload. Particularly on iPad.

I'm using cordova-plugin-ionic-webview on a PhoneGap Build project (diagnosing this issue has taught me to never use PGB again!), not as an ionic App. As such, I'm having issues running the app on emulators and getting at native logs that show anything useful.

The logging framework I use for in App JavaScript events doesn't show any JavaScript errors, but does show things are going normally and then the web view appears to reload for no reason (e.g the logging shows normal activity, then in the middle of a screen loading, the next log is code that only runs on app initialization - on the apps entry point - and should never be running again during the middle of a screen rendering, which indicates the web view has reloaded.

The crashes don't always happen at the exact same time or place on App, but the screen that crashes the most often is the most resource intensive screen of the App, including making dozens of requests to an external API. So it's possibly running out of Memory/CPU and causing the reload. Is that expected behavior? It seems strange to me that I've never seen similar behavior on much older Android devices and older versions of iOS where the hardware is likely to be much worse than what someone on iOS 12 is using. I also can't reproduce crashes in browser.

This issue may be relevant: https://stackoverflow.com/questions/51308181/cordova-app-reloads-itself-on-ios-12-iphonex

[maerlynflagg]

cordova-ios 5.0.0 cordova-plugin-ionic-webview 4.0.0

same for some of our users with an iOS 12 device. WebView/App crashes (whitescreen) and the webview do a reload (webViewWebContentProcessDidTerminate).

looks like random behavior.

[willcalderbank]

We seem to be seeing the same behaviour. Its not an ionic problem was im only using the ionic webview, not the framework

cordova-ios 5.0.0 cordova-plugin-ionic-webview 4.0.1

As @simonwatt said seems to be on loading the more intensive pages of the app. However according to xcode the app is never using more than 85mb and CPU usage never spikes about 10% (ipad pro 12.9 inch 3rd gen emulator)

Sorry for the edits:

The connecting the debugger on the resource intensive pages restart the app every time, in fact I have not seen the restart when the debugger was not connected. There are two canvases on the page where the restart takes place.

[simonwatt]

I ended up figuring out my App had a pretty bad memory leak, which was only occurring in Safari/iOS and not Chrome/Android. So in my case I think it's likely the issue is caused when memory usage gets very high, which is supported by some other reports I've read of WKWebView reloading when out of memory -- possibly iOS 12 has got more aggressive at killing the process, or maybe something changed with the WebKit GC and the leak has only started recently. Some of our users who have reported the crashes will soon be getting a new build, with fixes for the memory leak, so it will be interesting if the issue goes away.

[sithwarrior]

We have just experience the same issue.

We have an instance where a user is downloading aprox 65 files.

When using cordova-plugin-file-transfer all is fine, but since thats deprecated, we recently switched to using XMLHttpRequest . However when a user with these 65 files being downloaded at once, the webview reloads.

The load is higher using XMLHttpRequest.

This has been seen on ios 12.2 and ios 9.3.5

side note @simonwatt do you have any info on your memoryleak? as that would be nice to rule out.

[simonwatt]

side note @simonwatt do you have any info on your memoryleak? as that would be nice to rule out.

@sithwarrior The Web View reloading seems to be resolved since we fixed memory leaks on our App. In our specific case we are using React, and in several places we had API calls that were not getting cancelled correctly if the React component was unmounted before the promise resolved. Calling setState on the unmounted component was then causing memory to leak. Seems to be a pretty common pitfull for React developers: https://medium.freecodecamp.org/how-to-work-with-react-the-right-way-to-avoid-some-common-pitfalls-fc9eb5e34d9e. We also had a few setTimeOut calls, which are now explicitly getting cleared on componentWillUnmount, which seems to have helped.

In your case it sounds possible it's not necessarily a memory leak, but just attempting to use too much memory at once. I would suggest monitoring memory usage, to see if it is excessive (or leaking)... on iOS it's the 'com.apple.WebKit.WebContent' process you want to monitor... not what you will see in xCode profiler.

I'd be interested in exactly how much memory usage is usually enough to force the Web View to crash/reload. I found reproducing hard on Simulator as host machine had 16gb of RAM, and I couldn't mimic the hardware of an actual device.

[lucaryu78]

cordova-ios 5.0.1 cordova-plugin-ionic-webview 4.0.1

we found out that the web view crashes because the main thread used its capacity to 100%. This happens when files are read or rendered.

So the processes suspended and we got the following message:

2019-05-28 13:53:01.542675+0200 MyApp[4689:1736831] [ProcessSuspension] 0x2832bfc00 - ProcessAssertion() Unable to acquire assertion for process with PID 0

[platov]

ios: 12 cordova-ios 5.0.1 cordova-plugin-ionic-webview 4.0.1

We're experiencing the same issue. Our application, every 3 seconds, produce ~10 XHR requests, write and read File System(Logs), and do massive DOM Rendering(Angular). At random point of time the WebView reloads. While reloading there were not any bursts(high peak) of CPU, Memory or FS I/O.

[lucaryu78]

@platov the CPU itself is not exhausted. So you won’t see any cpu peaks. Only the main thread of the app is exhausted.

[platov]

Thanks, @luce78, we will try to monitor main thread at crash moment.

Also we disabled Logging to File system (read/write) operations and as result the crash rate significantly decreased. So we contninue work around FS...

[sithwarrior]

@luce78 That very interesting. Our useage is very similar, as we are writing about 65 files at once to the local filesystem for caching/offline use. and thats when the webview reloads/crashes.

Is anyone from Ionic watching this issue? Its preventing us, from delivering a good offline experience. We cant preload the files in the app, as its bespoke to the user.

[kitolog]

Hi there. We got the same issue, we are running read/write to the files several times per second, any updates with the (possible?) FS issue?

[mlynch]

Has anyone here used Capacitor and its Filesystem as a comparison to see if it has the same issue? It could be an issue w/ the file plugin from Cordova which is something we are trying to get people off of, either by using Capacitor or possibly porting the Capacitor one to Cordova if these issues can't be resolved

[adamduren]

@mlynch I do not have the cordova file plugin added to my project but still occasionally experience this issue. It doesn't sound like the author has the plugin either. Would be interested to know if people using capacitor have the issue as well though.

[platov]

UIWebview works as single process. WKWebview works as multi-process (In separate process).

Since WKWebview is separate process it names com.apple.WebKit.WebContent.

When that process crashes - the main application process(cordova+ionic webview) just re-create it(reload).

To retrieve the Crash Reports of WebContent proc do:

1. Connect Tablet/Phone to Mac
2. Open iTunes on Mac
3. Synchronize your Device
4. Find the crash logs at /Users/YOUR_USER/Library/Logs/CrashReporter/MobileDevice/

In my case while the main process consume ~50MB of memory and about ~30% of CPU the WebContent process consume up to 1GB of memory right before the crash. The crash report says the reason “Highwater” (A system daemon crossed its high water mark for memory usage.).

Actually our application has no memory leaks, but probably the random crashes are the moments when application(in WebView) tries to allocate too much memory at the one point of time.

How FS interaction may be related to this problem: In our case we use cordova-plugin-file cordova plugin. To write content to file, at WebView side, it converts all the Data to base64 string then send that string to native layer. The base64 string adds about 30% extra size from raw payload.

Can someone provide the crash reasons of WebContent proc in yours application ? If you use the FS and you suspect that FS is related to the Crash - can you measure how often do you write to FS and how big the size of writing payload ?

[lucaryu78]

The Ionic Team released cordova-plugin-ionic-webview version 4.1.0 Just update plugin version to 4.1.0 solved my problem.

This version includes the WKSuspendInBackground preference for iOS that prevents your web view from reloading when process is at its limit.

Hope it work for you too.

[adamduren]

@luce78 I looked at the code that introduced that preference. It appears to be using a private api so there's a chance apps using that version will get rejected. See commit has a base64 included string which decodes into alwaysRunsAtForegroundPriority. I'm guessing that's an attempt at obfuscating it from Apple. If you google that one it's a private API which is the reason why it was previously removed

[wilk-polarny]

Will there be a final solution for this issue? Our devices with iOS12 or newer experience these issues when launching a native window which overlays the webview. When being covered for too long, the webview will restart - possibly due to a too aggressive resource management by the OS? (we do OCR using a native plugin).

We never needed to disable WKSuspendInBackground - but might this help? Won't there be any problems due to the issue of using private APIs?

@mlynch @jcesarmobile

[gregavola]

@mlynch This appears to be never have been fixed, and WKWebview are crashing every day for us. Is there any light at the end here, or is this something that we have to deal with?

[platov]

The reason of WebView crash is - out of memory exception (try see crash report for wkwebview process)

The only thing that we can do - manage the memory usage of your JS application:

1. Resolve memory leaks.
2. Optimize memory usage.

Safari doesn't provide good devtools for this so i debug memory issues in Chrome Devtools, solve the issue then test result on Safari browser.

[mjayakumar2k6]

I am getting white screen issue after loading 159kb of JSON response. It works fine when the response is empty. Any solution?

[initru]

Spend few days on finding problem, on our case it was angular animation, mostly one that make transition between routes.

[wilk-polarny]

@initru interesting, could you provide more details?

[mjayakumar2k6]

@initru All our pages works fine. But it is happening in one page after some calculation and the iteration of huge data. It goes to the page shows the data and after 10 sec it is reloading and causing the white screen issue.

[mccainz]

Seeing this issue as well on a page running an expensive pathing algorithms (djikstra) as well as a MapboxGL animated map (lots of XHR tile requests).

[webfletch]

Is there still no update or solution for this? We are having the same problem, usually when saving to an API where it is sending a large amount of data in particular Base64 encoded images.

[ducminhquan]

Any updated on this issue? :( I have the same problem when request lots of XHR tile for mapbox gl.

[Pratz007-tech]

Is there a way to effectively load scripts ? I am struggling with white screen issue on ios 12 and lower versions, while on ios 13+ it works seamlessly (cordova-ios used is 6.1.1).While debugging on safari i could scripts are continuously loading in loop. Please let me know if any solution to this. Thanks & Kind Regards , Pratiksha

[joewoodhouse]

@ducminhquan Did you make any progress on this? I'm seeing very similar things in my app, and also using mapbox-gl

[messerram]

Is there a way to effectively load scripts ? I am struggling with white screen issue on ios 12 and lower versions, while on ios 13+ it works seamlessly (cordova-ios used is 6.1.1).While debugging on safari i could scripts are continuously loading in loop. Please let me know if any solution to this. Thanks & Kind Regards , Pratiksha

@Pratz007-tech could you solve this issue? I've the same issue withe the same versions you use.

[samuelbeaulieu]

Any update on this problem? Still getting it with my app. Loading 15k+ marker on a Google Map View.

[mccainz]

Any update on this problem? Still getting it with my app. Loading 15k+ marker on a Google Map View.

We have fought this issue for over a year and the only recourse we have found is to cut down your memory footprint / page size as much as possible. Profile for memory leaks, use lazy load strategies, optimize when and how you show your data etc.

[webfletch]

Any update on this problem? Still getting it with my app. Loading 15k+ marker on a Google Map View.

We have fought this issue for over a year and the only recourse we have found is to cut down your memory footprint / page size as much as possible. Profile for memory leaks, use lazy load strategies, optimize when and how you show your data etc.

This is the same for us, we were loading and saving Base64 images to and from local storage into memory, changed to use SQLite with some custom code so that could pull out or update just a single record from local storage (the Ionic local storage only lets you pull out all the data then filter what you need, all those records are put into memory when you might only need a few of them).

Made as many other optimisations as possible to ensure that we were loading the minimum amount into memory as possible and just pull things from SQLite when needed. I think the issue still occurs at times but not enough to cause major issues for users (well they haven't mentioned it in a while).

[ildar-dev]

Thank you so much for your help!

This problem was due to a large XHR request.

After adding some limits to get the data lists, the problem went away.