Bug 1020547

Summary:	Memory leak when closing dialog through UI plugin framework
Product:	[oVirt] ovirt-engine	Reporter:	Chris Morrissey <cmorriss>
Component:	Frontend.WebAdmin	Assignee:	Vojtech Szocs <vszocs>
Status:	CLOSED EOL	QA Contact:	bugs <bugs>
Severity:	unspecified	Docs Contact:
Priority:	low
Version:	---	CC:	bugs, cmorriss, ecohen, mgoldboi, rbalakri, sbonazzo, yeylon
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	ux
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-10-02 10:45:02 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	UX	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Chris Morrissey 2013-10-17 21:35:48 UTC

Description of problem:

Our application is a plugin for the UI and utilizes several dialogs that are opened using the plugin framework API openDialog(). The dialog shows content inside an iframe. When the dialog is closed, the memory taken when the dialog was opened is not released.

Note that this seems to be occurring both in IE 9/10 and Mozilla web browsers.

Version-Release number of selected component (if applicable):

oVirt 3.3

How reproducible:


Steps to Reproduce:
1. Create a basic UI plugin that adds a button somewhere in the UI that once clicked opens a dialog with any web page inside of it. It's easiest to see with a page that increases the memory usage significantly like another GWT app.
2. Watch the memory usage through Task Manager and open the dialog.
3. See that the memory rises as the page is loaded in the frame.
4. Close the dialog and see that the memory is not released.
5. Open the dialog again and the memory continues to increase.

Actual results:


Expected results:

The memory should be freed when the dialog closes.

Additional info:

Comment 1 Vojtech Szocs 2013-11-11 12:07:07 UTC

Hi Chris, thanks for reporting this issue!

Does the memory leak occur when closing the dialog using built-in mechanism (dialog close icon, Escape key), or using plugin API (api.closeDialog function), or both?

Each custom dialog opened via plugin API (api.showDialog function) is disposable (non-singleton) so most likely we're keeping a reference to the dialog class and/or its iframe element even after it's closed. I'll need to investigate this.

Chris, how severe is this issue?

Comment 2 Itamar Heim 2014-01-12 08:42:44 UTC

setting target release to current version for consideration and review. please do not push non-RFE bugs to an undefined target release to make sure bugs are reviewed for relevancy, fix, closure, etc.

Comment 3 Sandro Bonazzola 2014-03-04 09:21:10 UTC

This is an automated message.
Re-targeting all non-blocker bugs still open on 3.4.0 to 3.4.1.

Comment 4 Chris Morrissey 2014-04-03 15:25:40 UTC

Hi Vojtech,

Sorry for not getting back sooner on this. The issue definitely needs to be fixed at some point. We've just released and so far haven't hit any major issues with customers, but it could become a problem. In general a known memory leak like this really should be fixed if at all possible.

Comment 5 Sandro Bonazzola 2014-05-08 13:56:02 UTC

This is an automated message.

oVirt 3.4.1 has been released.
This issue has been retargeted to 3.5.0 since it has not been marked as high priority or severity issue, please retarget if needed.

Comment 6 Sandro Bonazzola 2015-09-04 09:01:29 UTC

This is an automated message.
This Bugzilla report has been opened on a version which is not maintained anymore.
Please check if this bug is still relevant in oVirt 3.5.4.
If it's not relevant anymore, please close it (you may use EOL or CURRENT RELEASE resolution)
If it's an RFE please update the version to 4.0 if still relevant.

Comment 7 Sandro Bonazzola 2015-10-02 10:45:02 UTC

This is an automated message.
This Bugzilla report has been opened on a version which is not maintained
anymore.
Please check if this bug is still relevant in oVirt 3.5.4 and reopen if still
an issue.

Comment 8 Chris Morrissey 2015-10-12 16:39:42 UTC

Ok to close. No longer an issue for us.