Closed msmtamburro closed 3 weeks ago
I think the fix would be to null out the webview in the plugin's dispose
method, since that is called when tearing down the view controller
I think the fix would be to null out the webview in the plugin's
dispose
method, since that is called when tearing down the view controller
This indeed did the trick. Adding ‘_engineWebView = nil;’ right before the [super dispose]; call is the only change needed.
It will take some time for me to get permission to raise this PR.
Feature Request
Even though there is an attempt to "clear out" the WKWebView in the
CDVViewController.m
dealloc method, the WKWebView inCDVWebViewEngine.m
is not simultaneously made nil, so it hangs around. I'd like to update these two classes to fully nil out WKWebView.Motivation Behind Feature
In an otherwise native app that includes Cordova as a Swift Package to occasionally open Cordova Web Views for specific features (e.g., the Platform Centered Approach) it is common to open and close CDVViewControllers in the course of a user session, as a user navigates around. Because there is no exposed method to fully destroy a WKWebView, all of the web views opened hang around, increasing system memory footprint (albeit outside of the host app's process).
Feature Description
I will likely just call a new method in dealloc, or I could leave it up to a platform centered approach consumer to make the call--I want to think about it a bit. This shouldn't have any impact on the non-platform centered approach, and we use that as well, so it should be easy to test both.
Alternatives or Workarounds
It's possible to mimic some of what's done in dealloc, and "lighten" the WKWebView by loading an empty string and removing script message handlers, but it would be better to just kill it when done.