UWP: Webview: Memory Leak #4720
Comments
|
Hello there! Hope you are having a good day. Any news on this? I'm curious to know if there is a work around for this. Cheers, Caleb |
|
Confirmed
|
|
Thanks mate! |
|
hi @samhouts. any updates on this? it looks like this was reported on UWP standalone apps too, not only XF and it looks like webview controller is leaking some memory in Back/Forward stack. |
|
Any updates on this issue? |
|
Just an update that might impact XF too. |
|
The memory leak is still in place. Same issue. Massive increase in memory on UWP. Android and IOS work fine. |
|
my tests showed memory handling improvements. Are you sure you've targeted >=RS3? or else, can you share a repro? |
|
Hello there, Spun up a fresh tabbed xamarin.forms app and experienced the same problem. Added a webview control to the ItemDetailPage and was able to get the memory leak to occur. Please see attached code. Using the latest updates with pre-releases. Problem is occurring on UWP. Please let me know what to change up to get this working. Cheers, Caleb |
|
One more thing. I think this issue has something to do with video players. When I browse to a somple website like: http://www.xamarin.com/ - There are no problems. Complex (normal news sites) crash this. Cheers, Caleb |
samhouts
added
inactive
|
Gang! I've got an app trending in the Microsoft store (Unfiltered.me) that really needs this fix. Is there anything I can do to move the ball forward? Do you have some pre-release builds that I can test? I I code the fix? |
|
I was curious about this issue and have had experience finding these kind of memory issues in the past. I see a difference in the UWP WebViewRenderer (Xamarin.Forms\Xamarin.Forms.Platform.UAP\WebViewRenderer.cs) when compared to the other platforms. This ones Dispose() does not remove the event handlers that get added to the Element in OnElementChanged, whereas all the other platforms seem to do this. Its been my experience that unremoved delegates can cause the GC to hold onto the objects, even when one might expect that they would go away themselves. I'd be willing to try this out however i've never contributed to XF before so not sure how to go about building and testing a locally build dll. Edit- Manual testing in the control gallery (using youtube.com as the website) suggests this change is good... before the change i could only navigate to the webview page 3 or 4 times before running out of memory. after the change, got no problems at all. if i can figure out how to encode this in a test case, i'll do a PR in the next day or so. |
Add option for custom renderers to control the execution mode of the WebView control
This is 'opt-in' as by default this commit will not change behavior of existing applciations. to opt-in, people would need to set the ExecutionMode property in the constructor of their custom WebViewRenderer, like:
public class MyWebViewRenderer : WebViewRenderer
{
public MyWebViewRenderer()
{
ExecutionMode = Windows.UI.Xaml.Controls.WebViewExecutionMode.SeparateProcess;
}
}
When set as 'SeparateProcess', the memory allocated by the WebView itself is all handled in a sub-process, which ensures the main process never crashes from running out of memory here from doing things like opening and closing youtube every 5 seconds. This behavior will likely crash when the WebView is in-process due to the huge amounts of memory that is required by that website.
Add option for custom renderers to control the execution mode of the WebView control
This is 'opt-in' as by default this commit will not change behavior of existing applciations. to opt-in, people would need to set the ExecutionMode property in the constructor of their custom WebViewRenderer, like:
public class MyWebViewRenderer : WebViewRenderer
{
public MyWebViewRenderer()
{
ExecutionMode = Windows.UI.Xaml.Controls.WebViewExecutionMode.SeparateProcess;
}
}
When set as 'SeparateProcess', the memory allocated by the WebView itself is all handled in a sub-process, which ensures the main process never crashes from running out of memory here from doing things like opening and closing youtube every 5 seconds. This behavior will likely crash when the WebView is in-process due to the huge amounts of memory that is required by that website.
samhouts
added
the
in-progress
PureWeen
added
the
blocker
|
I think I noticed this on a UWP project, perhaps having something to do w/ how the navigation system caches pages. (I could see them in "Microsoft Edge DevTools Preview") |
Add option for custom renderers to control the execution mode of the WebView control
This is 'opt-in' as by default this commit will not change behavior of existing applciations. to opt-in, people would need to set the ExecutionMode property in the constructor of their custom WebViewRenderer, like:
public class MyWebViewRenderer : WebViewRenderer
{
public MyWebViewRenderer()
{
ExecutionMode = Windows.UI.Xaml.Controls.WebViewExecutionMode.SeparateProcess;
}
}
When set as 'SeparateProcess', the memory allocated by the WebView itself is all handled in a sub-process, which ensures the main process never crashes from running out of memory here from doing things like opening and closing youtube every 5 seconds. This behavior will likely crash when the WebView is in-process due to the huge amounts of memory that is required by that website.
…12509) * To address issue #4720: Add option for custom renderers to control the execution mode of the WebView control This is 'opt-in' as by default this commit will not change behavior of existing applciations. to opt-in, people would need to set the ExecutionMode property in the constructor of their custom WebViewRenderer, like: public class MyWebViewRenderer : WebViewRenderer { public MyWebViewRenderer() { ExecutionMode = Windows.UI.Xaml.Controls.WebViewExecutionMode.SeparateProcess; } } When set as 'SeparateProcess', the memory allocated by the WebView itself is all handled in a sub-process, which ensures the main process never crashes from running out of memory here from doing things like opening and closing youtube every 5 seconds. This behavior will likely crash when the WebView is in-process due to the huge amounts of memory that is required by that website. * tabs not spaces * TemplatedItemsList: Ensure items are unhooked correctly when removing them, whether as individual removals or list resets. Without this, the native cells do not actually get removed. CellTableViewCell: use event PropertyChangedEventHandler instead of action (seems more standard) TextCellRenderer: Correct the event delegate hookup ListViewRenderer: Actually re-use the UITableViewCell when creating header sections, otherwise we endlessly create new ones, leaving the old ones alive through event handlers * Revert "TemplatedItemsList: Ensure items are unhooked correctly when removing them, whether as individual removals or list resets. Without this, the native cells do not actually get removed." This reverts commit 7da9ffb. * Make the custom renderer only apply to the test for this issue, as it seems the SeparateProcess affects access to cookies, breaking other tests * Move additional classes inside test class to decrease namespace cluttering. * - cleanup and rebase * - add instructions * - move WebViewExecutionMode to platform specific * - fix up UI Test * - clean up tests * - fix tabs * - fix formatting * - fix teardown call * - fix async ui test quirk on uwp Co-authored-by: Shane Neuville <shneuvil@microsoft.com>
…4720) (xamarin#12509) * To address issue xamarin#4720: Add option for custom renderers to control the execution mode of the WebView control This is 'opt-in' as by default this commit will not change behavior of existing applciations. to opt-in, people would need to set the ExecutionMode property in the constructor of their custom WebViewRenderer, like: public class MyWebViewRenderer : WebViewRenderer { public MyWebViewRenderer() { ExecutionMode = Windows.UI.Xaml.Controls.WebViewExecutionMode.SeparateProcess; } } When set as 'SeparateProcess', the memory allocated by the WebView itself is all handled in a sub-process, which ensures the main process never crashes from running out of memory here from doing things like opening and closing youtube every 5 seconds. This behavior will likely crash when the WebView is in-process due to the huge amounts of memory that is required by that website. * tabs not spaces * TemplatedItemsList: Ensure items are unhooked correctly when removing them, whether as individual removals or list resets. Without this, the native cells do not actually get removed. CellTableViewCell: use event PropertyChangedEventHandler instead of action (seems more standard) TextCellRenderer: Correct the event delegate hookup ListViewRenderer: Actually re-use the UITableViewCell when creating header sections, otherwise we endlessly create new ones, leaving the old ones alive through event handlers * Revert "TemplatedItemsList: Ensure items are unhooked correctly when removing them, whether as individual removals or list resets. Without this, the native cells do not actually get removed." This reverts commit 7da9ffb. * Make the custom renderer only apply to the test for this issue, as it seems the SeparateProcess affects access to cookies, breaking other tests * Move additional classes inside test class to decrease namespace cluttering. * - cleanup and rebase * - add instructions * - move WebViewExecutionMode to platform specific * - fix up UI Test * - clean up tests * - fix tabs * - fix formatting * - fix teardown call * - fix async ui test quirk on uwp Co-authored-by: Shane Neuville <shneuvil@microsoft.com>
Description
Using Xamarin.Forms (3.4.0.1008975), for UWP (windows 10) the webview control will take more and more memory space until it crashes the application
Steps to Reproduce
Expected Behavior
The webview control should closely mimic the resource allocation of Edge browser
Actual Behavior
After three or four navigation cycles (depends on webpage) the application crashes.
Basic Information
UWP (Windows 10)
Screenshots
http://dynamiconnections.com/downloads/screenshot.png
Reproduction Link
http://dynamiconnections.com/downloads/navigationsample.zip
The text was updated successfully, but these errors were encountered: