Bug Tracker

#8921 closed enhancement (fixed)

Opened April 19, 2011 09:16PM UTC

Closed September 19, 2011 08:13PM UTC

jQuery private data should stay private

Reported by: gnarf Owned by: gnarf
Priority: blocker Milestone: 1.7
Component: data Version: git
Keywords: 1.7-discuss Cc:
Blocked by: Blocking:
Description

It seems that the "private" data is ALWAYS stored on the 

.data(jQuery.expando)
- For "objects" where the deletion of the object should also delete its caches this makes some sense.

In the realm of nodes however, I think we should store these "private" members in a separate (private) cache so that they don't pollute the object returned by 

$.fn.data()

Attachments (0)
Change History (15)

Changed April 19, 2011 09:17PM UTC by gnarf comment:1

component: unfiled → data
owner: → gnarf
status: new → assigned

Changed May 22, 2011 07:27PM UTC by john comment:2

keywords: → 1.7-discuss

Nominating ticket for 1.7 discussion.

Changed May 22, 2011 09:13PM UTC by rwaldron comment:3

description: It seems that the "private" data is ALWAYS stored on the {{{.data(jQuery.expando)}}} - For "objects" where the deletion of the object should also delete its caches this makes some sense. \ \ In the realm of nodes however, I think we should store these "private" members in a separate (private) cache so that they don't pollute the object returned by {{{$.fn.data()}}} → It seems that the "private" data is ALWAYS stored on the {{{.data(jQuery.expando)}}} - For "objects" where the deletion of the object should also delete its caches this makes some sense.\ \ In the realm of nodes however, I think we should store these "private" members in a separate (private) cache so that they don't pollute the object returned by {{{$.fn.data()}}}

+0, Duplicates #8792

Changed May 23, 2011 12:40AM UTC by jaubourg comment:4

+1, I know the code would probably grow (I'm not so sure but heh) but I think it makes a lot of sense

Changed May 23, 2011 04:31AM UTC by timmywil comment:5

-1, use case where this is a problem?

Changed May 23, 2011 07:35PM UTC by gnarf comment:6

description: It seems that the "private" data is ALWAYS stored on the {{{.data(jQuery.expando)}}} - For "objects" where the deletion of the object should also delete its caches this makes some sense.\ \ In the realm of nodes however, I think we should store these "private" members in a separate (private) cache so that they don't pollute the object returned by {{{$.fn.data()}}} → It seems that the "private" data is ALWAYS stored on the {{{.data(jQuery.expando)}}} - For "objects" where the deletion of the object should also delete its caches this makes some sense. \ \ In the realm of nodes however, I think we should store these "private" members in a separate (private) cache so that they don't pollute the object returned by {{{$.fn.data()}}}

The reason I ran into the issue in the first place was that I changed the 

 .data()
behavior to store a flag in private data stopping it from scanning all the data- attribs more than once. Then a bunch of unit tests broke becuase it was using the 
jQuery.expando
key on the 
.data()
-- Basically, anytime you wanted to 
 for ... in
the 
 .data()
you're going to need to "ignore" the "private" data....

Changed May 24, 2011 12:47AM UTC by dmethvin comment:7

+1, I was thinking the same, worth considering with the "attach data to DOM elements" rewrite if it can be done

Changed May 24, 2011 12:54AM UTC by timmywil comment:8

priority: undecided → high

Changed June 03, 2011 01:55PM UTC by john comment:9

description: It seems that the "private" data is ALWAYS stored on the {{{.data(jQuery.expando)}}} - For "objects" where the deletion of the object should also delete its caches this makes some sense. \ \ In the realm of nodes however, I think we should store these "private" members in a separate (private) cache so that they don't pollute the object returned by {{{$.fn.data()}}} → It seems that the "private" data is ALWAYS stored on the {{{.data(jQuery.expando)}}} - For "objects" where the deletion of the object should also delete its caches this makes some sense.\ \ In the realm of nodes however, I think we should store these "private" members in a separate (private) cache so that they don't pollute the object returned by {{{$.fn.data()}}}

+0, Don't really have strong feelings on this.

Changed June 05, 2011 09:31PM UTC by ajpiano comment:10

description: It seems that the "private" data is ALWAYS stored on the {{{.data(jQuery.expando)}}} - For "objects" where the deletion of the object should also delete its caches this makes some sense.\ \ In the realm of nodes however, I think we should store these "private" members in a separate (private) cache so that they don't pollute the object returned by {{{$.fn.data()}}} → It seems that the "private" data is ALWAYS stored on the {{{.data(jQuery.expando)}}} - For "objects" where the deletion of the object should also delete its caches this makes some sense. \ \ In the realm of nodes however, I think we should store these "private" members in a separate (private) cache so that they don't pollute the object returned by {{{$.fn.data()}}}

+1, Seems to be part of fixing #8909

Changed July 12, 2011 02:48PM UTC by dmethvin comment:11

milestone: 1.next → 1.7
priority: high → blocker

Changed September 13, 2011 12:59AM UTC by gnarf comment:12

summary: jQuery private data should → jQuery private data should stay private

Changed September 13, 2011 06:40AM UTC by gnarf comment:13

https://github.com/jquery/jquery/pull/499

Pull currently closed while I look at another option.

Changed September 13, 2011 08:24AM UTC by gnarf comment:14

I think https://github.com/jquery/jquery/pull/500 turned out better than 499...

It changes it around so that instead of the "public data cache" storing the "private data" there is a "private data cache" which stores "public data"

Changed September 19, 2011 08:13PM UTC by Corey Frang comment:15

resolution: → fixed
status: assigned → closed

Landing pull request 500. 1.7 - "public data" stored as a key on "internal data" - Fixes #8921.

More Details:

Changeset: d5f144a7bba98212d6fe9e257f722b62baf651f0