I have a single page application with component programming. It has multiple pages out of which few of them have date picker in it. I found out my application was leaking and have detached nodes due to which the whole component stays in memory even after the user moves to a different page (destroying the component), GC was unable to clear it. after investigation, I found out that showdatepicker function stores the current DOM instance of datepicker to this._curInst into global space which is not getting cleared at the time of destroying datepicker, which is causing a leak.

I have created a small demo at ​https://jsfiddle.net/ksdsxhL1/1/

steps:

1. Open date picker by clicking on the input box once and close.
2. click on destroy button.
3. Open debugger and take heapsnapshot under memory and look for detached nodes. out of which look for the yellow node which shows reference to _curInst variable.

Tested on: Chrome, Mozilla Firefox, IE.

Temporary fix:

On destroying component or datepicker add this line

$.datepicker._curInst = null

If you are using Angular2 for eg.

ngOnDestroy(){
   $('#id').datepicker('destroy');
   $.datepicker._curInst = null
}

Observed behavior:

Requests to ​http://jqueryui.com succeed

Suggested behavior:

Requests to ​http://jqueryui.com should redirect to ​https://jqueryui.com

Security implications:

If this is not fixed, users will perform downloads using insecure HTTP, and will be subject to MITM attacks via DNS or via privileged network position.

Following up on case #15078:

The bug was fixed in the case above, but only for selectmenu's which are enabled.

The fix contains the creation of a new remove-eventhandler in the widget-function 'bindRemoveEvent()'.

Here the '_untrackClassesElement' - Handler is added on-remove. But the call misses the 'suppressDisabledCheck'-Flag, which makes it useless for disabled selecmenus.

Changing the Call to the following, fixes the bug:

that._on(true, $(element), {
    remove: "_untrackClassesElement"
});