[dhrothParticipant]

Sorry, I just saw this now. If it is too late for your use, I’ll post the example for the jqxGrid.js _addHandlers function anyway for others if needed.

First we defined a global JS variable that will hold a reference to the jqxGrid _addHandlers function. We null this variable when no longer needed.
var _jqxGrid_addHandlers_Func = null;

During our startup process, we make that assignment to save the reference to the function.
_jqxGrid_addHandlers_Func = $.jqx._jqxGrid.prototype._addHandlers;

Then we use jQuery to extend the jqxGrid object and override the _addHandlers function. When the _addHandlers function is called, we temporarily make the addEventListener and attachEvent methods on the window.top.document be an empty function that does nothing and then call the saved reference to the real _addHandlers jqxGrid function. We then put back the standard addEventListener and attachEvent methods on window.top.document.

We lose the jqxGrid handling of the mouseup when the user clicks in the grid and drags the mouse outside the grid before releasing the mouse button. We were willing to accept that in order to get rid of the memory leaks and browser crashes.

$.extend($.jqx._jqxGrid.prototype, {
    _addHandlers: function() {
        if (window.top != null && window.top != window.self && window.top.document) {
            if (window.top.document.addEventListener) {
                windowTopAddAttachEventListener = window.top.document.addEventListener;
                window.top.document.addEventListener = function(eventType, eventHandler, useCapture) {
                    return;  
                };
            } else if (window.top.document.attachEvent) {
                windowTopAddAttachEventListener = window.top.document.attachEvent;
                window.top.document.attachEvent = function(eventType, eventHandler) {
                    return;  
                };
            }
        }
        this.that = this;
        _jqxGrid_addHandlers_Func.call(this);
        if (window.top != null && window.top != window.self && window.top.document) {
            if (window.top.document.addEventListener) {
                window.top.document.addEventListener = windowTopAddAttachEventListener;
            } else if (window.top.document.attachEvent) {
                window.top.document.attachEvent = windowTopAddAttachEventListener;
            }
        }
        windowTopAddAttachEventListener = null;
    }
});

[dhrothParticipant]

The functions listed below in jqWidgets code have calls to window.top.document.addEventListener and window.top.document.attachEvent. There are other cases that we don’t use. The pattern seems to be that the event handler is defined in a local variable within these functions so that window.top.document has a reference to the local code. It doesn’t appear that objects are being leaked, but instead the JavaScript code itself is being leaked. When the page in the Iframe unloads, the script code can’t be released because the top document has a reference to it (at least in IE).

Our application has a static page containing an Iframe well where the guts of the application is loaded. As the user interacts with the application, the contents of the well Iframe are replaced. We have many instances of the grid within the application and each time a page with a grid is loaded into the Iframe, another 15-20 MB of memory is consumed as those event handlers are never released. After a few hours of working within the application our users would experience a browser crash which can be very costly when hospital clinicians are using these grids to see patient information when treating their patients.

Here are the files that we use that exhibit this behavior.
• jqxGrid.js – _addHandlers
• jqxGrid.columnsresize.js – _handlecolumnsresize
• jqxScrollbar.js – _addHandlers
• jqxbuttons.js – createInstance – calls addHandler passing window.top.document

Our only recourse was to override these functions with wrapper functions and in our wrapper stub out the window.top.document.addEventListener to suppress the registration of events there, then call the real jqx function, then put back the window.top.document.addEventListener. This was a hack that we really didn’t want to do, but didn’t have much choice in order to resolve the issues our users were experiencing.

It seems that the approach that the jqx code is using to add the mouseup listeners to window.top.document is not an ideal approach since there is no way to clean up those event handlers because the definition of the event handlers is in local variables in the code. It would be of great benefit to the jqWidgets user community if this approach for adding the event listeners to window.top.document were changed and if the event listeners were cleaned up so that the consuming application doesn’t have to figure out a way to do it.

[dhrothParticipant]

Ravi,

I know this post was from a couple of years ago, but I was wondering if you were able to come up with a way to remove the event handler in question. I am running into the same issue where we are experiencing a memory leak when running the jqxGrid in an iframe. If you came up with a way to resolve this, I’d appreciate knowing how you did it.

Thanks.

Dave Roth

[dhrothParticipant]

Thanks. At this time, we are not able to upgrade. We need to look into that on a release boundary.

However, we have found a workaround that seems to address the issue. If we implement a “ready” callback and call “setcolumnproperty” changing the width property for one of the columns to “auto”, the horizontal scrollbar does not appear and the columns resize appropriately when the browser window is resized.

When we get a chance to upgrade, we can then remove the workaround.

[Author]

Posts