Skip to main content

Search and Top Navigation

#10538 closed bug (notabug)

Opened August 11, 2014 06:52PM UTC

Closed August 20, 2014 12:31PM UTC

Potential memory leak in pseudo selectors

Reported by: dcherman1 Owned by:
Priority: minor Milestone: none
Component: ui.core Version: git (not yet released)
Keywords: Cc:
Blocked by: Blocking:

I can't think of a viable way to have a test case for this in a fiddle since jQuery's data cache is completely privatized in a closure, so I'll do my best to outline what I think happens.

If you have a detached set where someone does something like .filter( ":ui-spinner" ), the order of operations for that goes something like

1. !!$.data( elem, widgetName )

2. data_user.access( elem, name, data )

3. data_user.get( elem, name );

The third step there is the important one. Getting the data cache has the side effect of creating it if it didn't exist which means that unless the user knows to call .remove() on anything before discarding it, the cache contains objects that will never be cleaned up.

These pseudos should probably all call .hasData() before checking step #1 to ensure that they don't improperly cause the cache to be populated with an object for an operation that should not have side effects.

Attachments (0)
Change History (2)

Changed August 11, 2014 08:31PM UTC by tj.vantoll comment:1

Interesting. We require that users go through

(or other such methods) to avoid leaks, but I'm not necessarily against a safeguard like this. scott.gonzalez is away this week and I'm sure he has an opinion here.

Changed August 20, 2014 12:31PM UTC by scottgonzalez comment:2

resolution: → notabug
status: newclosed

There are no actual memory leaks when using the supported APIs. See comments in