Opened 8 years ago

Closed 8 years ago

#10538 closed bug (notabug)

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.

Change History (2)

comment:1 Changed 8 years ago by tj.vantoll

Interesting. We require that users go through remove() (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.

comment:2 Changed 8 years ago by Scott González

Resolution: notabug
Status: newclosed

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

Note: See TracTickets for help on using tickets.