Bug 1054242

Created attachment 851093 [details]
about:memory of Firefox 24.2.0 (firefox-24.2.0-6.el6_5.x86_64)

Created attachment 851095 [details]
about:memory of upstream Firefox 26.0

486.99 MB (32.18%) ── orphan-nodes
428.77 MB (28.33%) ── orphan-nodes

- it really does not look like a Firefox bug. Those nodes are owned by web(dom) but are not referenced.

Can you please attach "about:support" page?

Anyway, the orphan nodes are a bug in the WebApplication.

I see the orphan-nodes size in upstream Firefox are lower but they still are there. So it looks like a bug in the application, but upstream Firefox seems to run garbage collection more efficiently. 

Anyway, can you please provide us a testing instance? We don't see that on our testing system.

Also, please test different browsers (Chrome for instance).

And, is there any difference if you run GC manually? (Buttons in "Free memory" section, at about:memory page).

Thanks!

Created attachment 851165 [details]
about:support of Firefox 24.2.0 (firefox-24.2.0-6.el6_5.x86_64)

(In reply to Martin Stransky from comment #4)
> 486.99 MB (32.18%) ── orphan-nodes
> 428.77 MB (28.33%) ── orphan-nodes
> 
> - it really does not look like a Firefox bug. Those nodes are owned by
> web(dom) but are not referenced.
> 
> Can you please attach "about:support" page?

Attached.

(In reply to Martin Stransky from comment #5)
> Anyway, the orphan nodes are a bug in the WebApplication.
> 
> I see the orphan-nodes size in upstream Firefox are lower but they still are
> there. So it looks like a bug in the application, but upstream Firefox seems
> to run garbage collection more efficiently. 
> 
> Anyway, can you please provide us a testing instance? We don't see that on
> our testing system.
> 
> Also, please test different browsers (Chrome for instance).
> 
> And, is there any difference if you run GC manually? (Buttons in "Free
> memory" section, at about:memory page).
> 
> Thanks!

I'll try the Chromium browser over the night as well as FF manual garbage collection and post my findings here tomorrow. 
I'll also send you access to my testing machine & RHEVM instance so you can take a look by yourself.

(setting needinfo to myself again so I don't forget :) )

Created attachment 851597 [details]
memory stats from FF24 ESR (with manual GC) and Chromium 31

(In reply to Martin Stransky from comment #5)
> Anyway, the orphan nodes are a bug in the WebApplication.
> 
> I see the orphan-nodes size in upstream Firefox are lower but they still are
> there. So it looks like a bug in the application, but upstream Firefox seems
> to run garbage collection more efficiently. 
> 
> Anyway, can you please provide us a testing instance? We don't see that on
> our testing system.

I have sent you e-mail with access to my testing machine & RHEVM instance.

> 
> Also, please test different browsers (Chrome for instance).

I tried Chromium 31 and it consumes about half amount of memory than FF24 does.
 
> 
> And, is there any difference if you run GC manually? (Buttons in "Free
> memory" section, at about:memory page).
> 

I went through all buttons in the "Free Memory" section, but it didn't seem to make any difference. 

All memory stats from Chromium and FF are attached.

I'm unable to reproduce on regular Firefox 18/19 installation. I'm going to test the RHEL boxes.

I mean Firefox 26 on Fedora 18/19, x86_64, bare metal. Can we get more testers here? Ant without the VM/VNC, just basic setup.

There's no difference between our Firefox 24.2 ESR build and upstream 24.2 ESR in memory lost by orphan-nodes. Firefox 26 seems to be better. I'll investigate it further.

Mozilla bug for reference:
https://bugzilla.mozilla.org/show_bug.cgi?id=964187

This issue is related to https://pn-rhsetup.rhev.lab.eng.brq.redhat.com/webadmin/webadmin/clear.cache.gif image.

According to https://bugzilla.mozilla.org/show_bug.cgi?id=964187#c14 web application could fix this problem by avoiding operation with clear.cache.gif.

Mozilla say that bug fixed in FF 26 only reduce orphan nodes, not getting rid of all of them. I can observe the same result. Orphan nodes are growing in Firefox 24 and 26, however in 24 much more significant.

Unfortunately JS code of RHEVM is quite obfuscated/generated? and difficult to debug.

Since I didn't find any bug report about growing orphan nodes in Mozilla bugzilla you can most likely fix it in your application.

Backporting the patch, which reduce orphan nodes memory but not actually get rid of them, to ESR 24 is no simple task, because a lot of code changed between 24 and 26 and it seems Mozilla is most likely not willing to backport it to 24ESR.

(In reply to Jan Horak from comment #14)
> According to https://bugzilla.mozilla.org/show_bug.cgi?id=964187#c14 web
> application could fix this problem by avoiding operation with
> clear.cache.gif.
> 
> [...snip...]
> 
> Backporting the patch, which reduce orphan nodes memory but not actually get
> rid of them, to ESR 24 is no simple task, because a lot of code changed
> between 24 and 26 and it seems Mozilla is most likely not willing to
> backport it to 24ESR.

Thanks Jan for looking into it! Adding RHEVM R&D...

@Einav, is there a way how to solve the situation with clear.cache.gif images in GWT?

(In reply to Pavel Novotny from comment #15)
> (In reply to Jan Horak from comment #14)
> > According to https://bugzilla.mozilla.org/show_bug.cgi?id=964187#c14 web
> > application could fix this problem by avoiding operation with
> > clear.cache.gif.
> > 
> > [...snip...]
> > 
> > Backporting the patch, which reduce orphan nodes memory but not actually get
> > rid of them, to ESR 24 is no simple task, because a lot of code changed
> > between 24 and 26 and it seems Mozilla is most likely not willing to
> > backport it to 24ESR.
> 
> Thanks Jan for looking into it! Adding RHEVM R&D...
> 
> @Einav, is there a way how to solve the situation with clear.cache.gif
> images in GWT?

@Vojtech?

Thanks to Jan Horak and Martin Stransky for looking into this issue in relation to Firefox 24 ESR. Below are my notes on the matter.

A. Orphan nodes
---------------

By definition, these are "nodes that are currently not part of a live document (reachable from a window object)" [1].

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=704623#c0

RHEV GUI (WebAdmin/UserPortal) is dynamic web application, i.e. DOM nodes are dynamically created and attached/detached to/from DOM document tree using JavaScript. The important question here is if there's any JavaScript code still referencing DOM nodes *which are not currently attached to live document*, which prevents garbage collection (memory reclamation) of such DOM nodes.

The answer to above question is *singleton* UI components - consider following WebAdmin use-case:

a1. open "Virtual Machines" tab
    - VM tab UI is created and attached to live document
a2. switch to "Data Centers" tab
    - VM tab UI is detached from live document
    - DC tab UI is created and attached to live document
a3. switch back to "Virtual Machines" tab
    - DC tab UI is detached from live document
    - VM tab UI is *re-attached* to live document

The main idea here is avoiding DOM manipulation which imposes performance penalty:
* the good = we can reuse existing UI by avoiding DOM manipulation
* the bad  = we will always get some orphan nodes due to this technique

(Note: all dialogs in RHEV GUI are non-singleton UI components.)

Given the orphan node memory profile is acceptable in Firefox 17 ESR or 26, I don't think that orphan nodes are the main problem here. I think the main problem is Firefox 24 ESR wasting too much memory on orphan nodes, i.e. browser-specific regression related to memory changes introduced in Firefox 24.

To be honest, I'm wondering how could such memory changes, with obvious regression potential, get into Firefox 24 which was marked as ESR release.

B. clear.cache.gif image
------------------------

This is 1x1 image used to implement "Image Bundle" feature in GWT [2], i.e. pack multiple smaller images into one big PNG image and reference portions (clipped areas) of big image on client.

[2] http://code.google.com/p/google-web-toolkit/wiki/ImageBundleDesign#Clipping_Constructor_for_Image

For example:

<img src="clear.cache.gif" style="background-image:md5.cache.ext; background-position:-Xpx -Ypx; width:Wpx; height:Hpx">

As you can see, clear.cache.gif is just a placeholder (blank) image to satisfy HTML spec. The actual image is rendered via CSS, i.e. clipped portion of md5.cache.ext big image.

The important thing here is that clear.cache.gif + big image files *should be always cached* on client. When RHEV GUI code creates <img> node like above, clear.cache.gif should *not* be retrieved each time from server.

In RHEV GUI, we have following (HTTP response header) caching policy for all PNG and GIF images, i.e. including clear.cache.gif and all big image files:
* Expires: <now + 1 year>
* Cache-Control: <1 year>
* Pragma: <empty string>

So to my knowledge, we instruct Firefox to cache all images forever, using CSS to achieve image clipping functionality. Therefore the issue with clear.cache.gif seems like a Firefox bug, rather than RHEV GUI bug. Perhaps someone from Firefox team could look into this.

> According to https://bugzilla.mozilla.org/show_bug.cgi?id=964187#c14 web application could fix this problem by avoiding operation with clear.cache.gif.

As mentioned above, we can't avoid operation with clear.cache.gif.

> Unfortunately JS code of RHEVM is quite obfuscated/generated? and difficult to debug.

If you want to look into RHEV GUI JavaScript code that is un-optimized and un-obfuscated, this can be done by building RHEV with special flags [3].

[3] http://www.ovirt.org/DebugFrontend#GWT_Draft_Compile

> Since I didn't find any bug report about growing orphan nodes in Mozilla bugzilla you can most likely fix it in your application.

Please see my notes on orphan nodes above, there will always be some orhpan nodes, depending on how much singleton-based UI has been created (triggered by end user navigating throughout web application's UI).

> Backporting the patch, which reduce orphan nodes memory but not actually get rid of them, to ESR 24 is no simple task, because a lot of code changed between 24 and 26 and it seems Mozilla is most likely not willing to backport it to 24ESR.

Yes, according to [4] it's likely that they won't fix the regression in orphan node memory profile at all.

[4] https://bugzilla.mozilla.org/show_bug.cgi?id=964187#c2

So for now, I'd say the best approach is to simply avoid Firefox 24 ESR, i.e. use Firefox 17 ESR if possible.

If someone wants to perform further analysis, I strongly suggest to use RHEV GUI build that is un-optimized and un-obfuscated, i.e. able to trace problematic code in JavaScript.

Thanks, Vojtech. 

Bottom line:

- yes, we have orphan nodes "by design" - it never prevented our applications from working well on FF17 as well as FF26. FF24 shouldn't be any different. 

- clear.cache.gif is internally used within the GWT infrastructure and is probably not the source of the problem anyway due to our caching policies. 

-> we cannot do anything in the application code in order to improve the situation on FF24. 

ATM, RHEV-M GUI is supported only on FF17. 

we will be happy to try and assist the FF team with providing a RHEV-M build with an un-optimized and un-obfuscated java-script for easier debugging, if necessary. 

@Andrew - any recommendations on how to proceed?

What would be great here is to have some testcase that we can attach to Mozilla bug. 
> we will be happy to try and assist the FF team with providing a RHEV-M build with an un-optimized and un-obfuscated java-script for easier debugging, if necessary. 

That could help in making testcase. I'm not sure I can make by myself as long as I'm no expert in webapps, but at least we can try.

Problem is that ESR 17 is no longer supported by security updates and for doing backport for each security update we don't have enough manpower.

(In reply to Einav Cohen from comment #20)
> ATM, RHEV-M GUI is supported only on FF17. 

Well, Firefox 17 is outdated, unsupported and contains knows security issues. 

Latest official versions distributed by Mozilla, Red Hat and others are Firefox 27 and Firefox 24 ESR. 

So there's no point to talk about Firefox 17 because nobody should run it - unless you have this old version installed for the RHEV portal only.

(In reply to Martin Stransky from comment #22)
> (In reply to Einav Cohen from comment #20)
> > ATM, RHEV-M GUI is supported only on FF17. 
> 
> Well, Firefox 17 is outdated, unsupported and contains knows security
> issues. 
> 
> Latest official versions distributed by Mozilla, Red Hat and others are
> Firefox 27 and Firefox 24 ESR. 
> 
> So there's no point to talk about Firefox 17 because nobody should run it -
> unless you have this old version installed for the RHEV portal only.

what is the FF17 alternative that you are suggesting?

It looks like there's no alternative right now, as far as the Firefox 27 also contains this bug (Bug 1036443). So we need to fix that, on the Firefox side or on the RHEV side. I think we can investigate both ways.

For the Firefox side - we need a testcase. Please, can you provide such testcase for us? I think you may be able to emulate the usage of clear.cache.gif on some plain web page, without the RHEV.

(In reply to Martin Stransky from comment #24)
> It looks like there's no alternative right now, as far as the Firefox 27
> also contains this bug (Bug 1036443). So we need to fix that, on the Firefox
> side or on the RHEV side. I think we can investigate both ways.
> 

Some findings on this topic are described in comment 19 by Vojtech (from RHEVM R&D).

> For the Firefox side - we need a testcase. Please, can you provide such
> testcase for us? I think you may be able to emulate the usage of
> clear.cache.gif on some plain web page, without the RHEV.

We (QA) don't have any test case for usage of the clear.cache.gif, neither in emulated environment nor in RHEVM itself.
But we can helpfully provide to FF team a RHEVM build for testing and assist.

(In reply to vszocs from comment #19)
> The answer to above question is *singleton* UI components - consider
> following WebAdmin use-case:
> 
> a1. open "Virtual Machines" tab
>     - VM tab UI is created and attached to live document
> a2. switch to "Data Centers" tab
>     - VM tab UI is detached from live document
>     - DC tab UI is created and attached to live document
> a3. switch back to "Virtual Machines" tab
>     - DC tab UI is detached from live document
>     - VM tab UI is *re-attached* to live document

So when the ajax query is done (like UI refresh) are you actually also changing/updating DOM of hidden tab (and currently orphaned nodes) or do you only update data on visible/live tab? I need to figure it out if off DOM operations are actually creating the leak.

Problem seems to be that the IMG elements clear.cache.gif actually contains img data as part of element. When these are not properly disposed (by webapp or firefox) can fill memory quite fast.

> So when the ajax query is done (like UI refresh) are you actually also
> changing/updating DOM of hidden tab (and currently orphaned nodes) or do you
> only update data on visible/live tab?

To my knowledge, in general, we only update DOM elements that are currently visible (part of live document). DOM updates can be triggered by things like automatic data refresh (AJAX) callbacks and, of course, user interaction.

Some technical details:
* our UI business logic layer (UiCommon) does automatic data refresh only for currently visible UI components (with multiple distinct UI components visible at the same time, there might be multiple corresponding AJAX requests)
* we use Model-View-Presenter framework (GWT-Platform) in a way that UI component updates are done mostly when the component is already visible (onReset) or about to become visible (onReveal), i.e. no special logic when the component is about to become detached (onHide)

As mentioned above, singleton UI components are just detached from live document and re-attached later if needed (updates on detached DOM elements shouldn't occur in general). Generally speaking, most UI except dialogs is singleton-based, so observing orphan nodes is a logical (and expected) consequence.

> I need to figure it out if off DOM operations are actually creating the leak.

We can provide special RHEV build with un-optimized un-obfuscated UI (JavaScript) for easier debugging. Is there some tool we can use with Firefox to detect off-DOM operations that could cause memory leaks?

> Problem seems to be that the IMG elements clear.cache.gif actually contains
> img data as part of element. When these are not properly disposed (by webapp
> or firefox) can fill memory quite fast.

Yes, <img> element points to actual image data via CSS style attribute. Hm, how can we "properly dispose" such elements? For <img> element that is part of singleton UI component, no special disposal is done - element is simply detached from live document upon "hiding" of given component.

> Is there some tool we can use with Firefox to detect off-DOM operations that could cause memory leaks?

AFAIK no.

> Yes, <img> element points to actual image data via CSS style attribute. Hm, how can we "properly dispose" such elements? For <img> element that is part of singleton UI component, no special disposal is done - element is simply detached from live document upon "hiding" of given component.

In Javascript there's remove [1] or removeChild [2] method. Without un-obfuscated UI we won't go any further. 

[1] https://developer.mozilla.org/en-US/docs/Web/API/ChildNode.remove
[2] https://developer.mozilla.org/en-US/docs/Web/API/Node.removeChild

> In Javascript there's remove [1] or removeChild [2] method.

In GWT, removeChild DOM API maps to com.google.gwt.dom.client.Node#removeChild + com.google.gwt.user.client.DOM#removeChild

Looking at Widget#onDetach base implementation, by default it does not remove widget's DOM element, it just clears the event listener on that DOM element:

  elem.__listener = null;

For widgets implementing HasWidgets interface (logical containers such as panels), HasWidgets#remove removes child widgets. For panels nesting child DOM elements, typical HasWidgets#remove implementation [1] looks like this:

  a, detach child widget via Widget#onDetach
  b, clear child widget's reference to parent widget
  c, call (parent)Node#removeChild(childElement) -> physical detach
  d, clear parent widget's reference to child widget -> logical detach

[1] com.google.gwt.user.client.ui.SimplePanel#remove

So it seems that GWT indeed seems to be "properly disposing" child DOM elements with regard to logical container (panel) widgets.

> Without un-obfuscated UI we won't go any further. 

Fully agreed.

Details are here: http://www.ovirt.org/DebugFrontend#GWT_Draft_Compile

(Pavel, if you need assistance with this, please let me know.)

Please provide us the un-obfuscated UI so we can proceed further.

Hi Jan/Martin, any progress?

(In reply to Einav Cohen from comment #33)
> Hi Jan/Martin, any progress?

It would help us if you can install and set up the test un-obfuscated & un-optimized server for us. We don't have any available box for it right now.

(In reply to Martin Stransky from comment #34)
> (In reply to Einav Cohen from comment #33)
> > Hi Jan/Martin, any progress?
> 
> It would help us if you can install and set up the test un-obfuscated &
> un-optimized server for us. We don't have any available box for it right now.

@Pavel - per your offer to help in comment #32: any chance that you can assist here with installing the the RPMs mentioned in comment #31 on one of your boxes and provide it to Martin's team for further investigation of the issue?

many thanks in advance.

@Martin - is there anything else that you need in order to proceed with the investigation? 
please keep us posted on the status of this issue. 
thanks.

Pavel promised to configure the test box according the original one to reproduce the issue.

(In reply to Martin Stransky from comment #39)
> Pavel promised to configure the test box according the original one to
> reproduce the issue.

@Pavel - are you on it?

(In reply to Einav Cohen from comment #40)
> (In reply to Martin Stransky from comment #39)
> > Pavel promised to configure the test box according the original one to
> > reproduce the issue.
> 
> @Pavel - are you on it?

Yes, I added a host and storage to the testing RHEVM instance. From now it's possible to manage VMs, templates, VM pools, etc.

(In reply to Pavel Novotny from comment #41)
> (In reply to Einav Cohen from comment #40)
> > (In reply to Martin Stransky from comment #39)
> > > Pavel promised to configure the test box according the original one to
> > > reproduce the issue.
> > 
> > @Pavel - are you on it?
> 
> Yes, I added a host and storage to the testing RHEVM instance. From now it's
> possible to manage VMs, templates, VM pools, etc.

Many thanks, Pavel.
@Martin - is there anything else that you need in order to proceed with the investigation?

I guess we have everything we need, Thanks!

Note: A testcase is to open the webpage with long list (scroll bars has to be rendered) and leave it open on top. It can't be hidden, minimized or so.

Btw. The image cache is heavily used - 200MB orphan nodes means that the cache contains 25 000 instances of the clear.cache.gif image.

We found where the problem is. 

Can you also test a workaround? Open "about:config" and set "layout.imagevisibility.enabled" preference to "false". It disables image visibility management.

(In reply to Martin Stransky from comment #46)
> We found where the problem is. 
> 
> Can you also test a workaround? Open "about:config" and set
> "layout.imagevisibility.enabled" preference to "false". It disables image
> visibility management.

Sounds great Martin, thanks! 
I'll try the workaround with the "layout.imagevisibility.enabled" disabled. I'll leave Firefox with RHEVM opened overnight as you wrote in comment 44 and tomorrow I'll let you know with the memory statistics.

Seems to be related to https://bugzilla.mozilla.org/show_bug.cgi?id=689623

Martin, status/progress?

(In reply to Einav Cohen from comment #51)
> Martin, status/progress?

?

only now saw comment #46 and comment #47.
@Pavel - any updates on your end?

(In reply to Einav Cohen from comment #53)
> only now saw comment #46 and comment #47.
> @Pavel - any updates on your end?

After a mistake in my yesterday measurement I am running a second round on the FF with and without the "layout.imagevisibility.enabled" set. I should have results of the memory usage within an hour.

Created attachment 876443 [details]
FF24 RHEVM mem usage "layout.imagevisibility.enabled" comparison

Attaching FF memory usage logs with different "layout.imagevisibility.enabled" option set.

The memory usage didn't went through the roof in neither case.
The RAM usage difference wasn't really tremendous - 765 MB (*) vs. 674 MB (**) after one hour with one opened FF window with RHEVM on VMs tab with 500 VMs.

[*]  layout.imagevisibility.enabled option wasn't present in about:config
[**] layout.imagevisibility.enabled=false

(In reply to Pavel Novotny from comment #56)
> The memory usage didn't went through the roof in neither case.
> The RAM usage difference wasn't really tremendous - 765 MB (*) vs. 674 MB
> (**) after one hour with one opened FF window with RHEVM on VMs tab with 500
> VMs.
> 
> [*]  layout.imagevisibility.enabled option wasn't present in about:config
> [**] layout.imagevisibility.enabled=false

Pavel, I don't see much memory raise here. The initial memory consumption is  ~550MB, after hour it's 670 MB (or 750MB). 

Actually it does not look like a problem to me. The initial orphan-nodes size is 40 - 50 MB and it does not change much from the start.

It would help to run it over night or so, but I believe with layout.imagevisibility.enabled=false the overal memory size wont be much bigger than the 600-700MB.

Anyway, there's also garbage collector involved. 

With layout.imagevisibility.enabled=false the memory usage can oscillate between 500-700 MB but it should not raise dramatically above 800-900MB or so. 

From my experience if you go to about:memory and try "Minimize memory usage" the memory drops to the initial values around 550MB.

(In reply to Martin Stransky from comment #58)
> (In reply to Pavel Novotny from comment #56)
> > The memory usage didn't went through the roof in neither case.
> > The RAM usage difference wasn't really tremendous - 765 MB (*) vs. 674 MB
> > (**) after one hour with one opened FF window with RHEVM on VMs tab with 500
> > VMs.
> > 
> > [*]  layout.imagevisibility.enabled option wasn't present in about:config
> > [**] layout.imagevisibility.enabled=false
> 
> Pavel, I don't see much memory raise here. The initial memory consumption is
> ~550MB, after hour it's 670 MB (or 750MB). 
> 
> Actually it does not look like a problem to me. The initial orphan-nodes
> size is 40 - 50 MB and it does not change much from the start.
> 
> It would help to run it over night or so, but I believe with
> layout.imagevisibility.enabled=false the overal memory size wont be much
> bigger than the 600-700MB.

Yes, the RAM usage didn't went up much after one hour.

I'll run the browser with "layout.imagevisibility.enabled=false" for longer time.
Starting it now, I'll post the memory usage log in the evening after several hours running and next one tomorrow morning.

Created attachment 878025 [details]
RHEVM - FF24 memreport with "layout.imagevisibility.enabled=false" after 4 days

I left the browser opened for 4 days just with one window with RHEVM (swithed on the Virtual Machines tab) and set option "layout.imagevisibility.enabled=false".
Over the 4 days the memory usage went from 570 MB to 2.2 GB, see attached memory reports for details.

Pavel, thanks for the info. I see only 11MB of orphan-nodes after 4 days which looks good. The main memory usage is: 

1,618.86 MB (71.87%) ── heap-unclassified

which is a general memory used by Firefox. It can be shrink by "Minimize memory usage" or automatically by Firefox memory management. This heap memory is not related to this bug - mem peaks caused by dynamic image management.

From this testing I'd say the workaround works as expected.

layout.imagevisibility.enabled=false is a formal workaround and it disables firefox image optimization management. 

The image optimization management pre-loads the images and releases invisible images and tries to optimize memory usage. It does not affect web pages look.

(In reply to Martin Stransky from comment #66)
> layout.imagevisibility.enabled=false is a formal workaround and it disables
> firefox image optimization management. 
> 
> The image optimization management pre-loads the images and releases
> invisible images and tries to optimize memory usage. It does not affect web
> pages look.

After discussing the above with RHEV Program/Product Management:

The above means that each and every RHEV consumer will 
need to manually configure each and every FF24 browser 
in order to allow the RHEV-M GUI to behave properly. 

This is not an acceptable solution. 

FF24 is an ESR version, it needs to behave properly. 

Since the RHEV-M GUI behaves well in the previous ESR version 
(FF17) and does not behave well in the current ESR version 
(FF24), it is a FF regression that must involve a FF fix. 

Which means that FF team need to do whatever needs to be done 
in order to make sure that the RHEV-M GUI behaves properly on 
FF24 out of the box, without needing to manually configure 
anything. 

IIUC, one of the options is to backport the relevant fix from 
FF26 to FF24 (which should reduce the orphan nodes memory). 
According to Comment #14, we understand that backporting this 
fix is not an easy task, however we request that you will look 
into this possibility again (and/or advise on any other 
solution that you can think of). 

Many thanks in advance.

(In reply to Einav Cohen from comment #67)
> After discussing the above with RHEV Program/Product Management:
> 
> The above means that each and every RHEV consumer will 
> need to manually configure each and every FF24 browser 
> in order to allow the RHEV-M GUI to behave properly. 
> 
> This is not an acceptable solution. 

How many users are we talking about here? 

Anyway, the configuration can be automated - you just need to create a .js file with that preference and put it to "/usr/lib(64)/firefox/browser/defaults/preferences". 

> FF24 is an ESR version, it needs to behave properly. 
> 
> Since the RHEV-M GUI behaves well in the previous ESR version 
> (FF17) and does not behave well in the current ESR version 
> (FF24), it is a FF regression that must involve a FF fix. 
> 
> Which means that FF team need to do whatever needs to be done 
> in order to make sure that the RHEV-M GUI behaves properly on 
> FF24 out of the box, without needing to manually configure 
> anything. 

Correct. But RHEV-M GUI users are not the only ones who run Firefox on RHEL. We need to balance requests to make sure it works well for the majority of the user base.

> IIUC, one of the options is to backport the relevant fix from 
> FF26 to FF24 (which should reduce the orphan nodes memory). 
> According to Comment #14, we understand that backporting this 
> fix is not an easy task, however we request that you will look 
> into this possibility again (and/or advise on any other 
> solution that you can think of). 

The backport is out of the question. The fix is too intrusive and actually does not solve it - just moves it further. Core of the patch is completely different image management which involves image decoding a caching, it's not just simple array->hash table change. 

Also next Firefox ESR release is going to be Firefox 31. Firefox 31 is going to be released in July and we're going to replace Firefox 24 with it. 

So I propose to keep the workaround until Summer when Firefox 31 will be here. We also need to look at actual fix which will check the image visibility and remove dynamically inserted invisible images.

Martin, AFAIK we only support RHEL+FF or WIN+IE combinations for using the RHEV portal:

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.3/html/Administration_Guide/sect-Using_the_Administration_Portal_Graphical_Interface.html

Other OS+Browser combinations usually work but are not officially supported at the moment.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2014-0448.html