Bug 1020547 - Memory leak when closing dialog through UI plugin framework
Memory leak when closing dialog through UI plugin framework
Product: ovirt-engine
Classification: oVirt
Component: Frontend.WebAdmin (Show other bugs)
Unspecified Unspecified
low Severity unspecified (vote)
: ovirt-3.6.0-rc
: 3.6.0
Assigned To: vszocs
Depends On:
  Show dependency treegraph
Reported: 2013-10-17 17:35 EDT by Chris Morrissey
Modified: 2016-02-10 14:22 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-10-02 06:45:02 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: UX
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
ylavi: ovirt‑3.6.0?
ylavi: planning_ack?
ylavi: devel_ack?
ylavi: testing_ack?

Attachments (Terms of Use)

  None (edit)
Description Chris Morrissey 2013-10-17 17:35:48 EDT
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 vszocs 2013-11-11 07:07:07 EST
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 03:42:44 EST
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 04:21:10 EST
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 11:25:40 EDT
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 09:56:02 EDT
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 05:01:29 EDT
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 06:45:02 EDT
This is an automated message.
This Bugzilla report has been opened on a version which is not maintained
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 12:39:42 EDT
Ok to close. No longer an issue for us.

Note You need to log in before you can comment on or make changes to this bug.