Skip to main content

Bug Tracker

Side navigation

#6754 closed bug (invalid)

Opened July 01, 2010 07:47PM UTC

Closed November 03, 2010 04:26PM UTC

Last modified September 07, 2011 10:51PM UTC

a.find(b) produces bad selector if a or b have grouped selectors

Reported by: Phrogz Owned by:
Priority: low Milestone: 1.5
Component: selector Version: 1.4.2
Keywords: find pushstack selector Cc:
Blocked by: Blocking:
should produce something like
'a c,a d,b c,b d'
. Instead, it produces
'a,b c,d'
in jQuery 1.4.2.

This breaks any code that uses the selector for future live-like selections or tests.

Attachments (0)
Change History (10)

Changed July 01, 2010 07:54PM UTC by Phrogz comment:1

This is fixed by this git commit in my fork. Awaiting a merge from my pull request.

Changed July 01, 2010 07:57PM UTC by Phrogz comment:2

Oops; that commit had some text accidentally deleted right before commit. Corrected commit here:

Changed November 03, 2010 03:34AM UTC by boushley comment:3

Here's a link for a valid jsfiddle test case I can't speak to the validity of the commits however.

Changed November 03, 2010 03:45AM UTC by SlexAxton comment:4

component: coreselector
priority: → low
status: newopen

This seems like a better representation of what he's asking:

I am not sure jQuery intentionally tries to support comma delimited selectors in a find() statement. It definitely has never supported this, so it isn't a regression, but I consider it something that seems like it should work. Until then, you can just use an add() statement or be explicit.


Changed November 03, 2010 03:48AM UTC by boushley comment:5

Here's an updated fiddle that better shows the fact that two different sets are selected.

Changed November 03, 2010 12:06PM UTC by cowboy comment:6

_comment0: Passing a comma-delimited selector string to `.find('c,d')` should be a very common use case! \ \ In addition, because `jQuery('foo', context)` uses `jQuery(context).find('foo')` internally, `.find` MUST support every selector that `jQuery()` supports.1288786121852147

n/m this comment!

Changed November 03, 2010 12:06PM UTC by cowboy comment:7

_comment0: Ah but the .selector property... is there any way to tell people to stop using it? :/1288786107960531
_comment1: Oops.. I mis-read the description. That .selector property... People need to be made to understand that it's a very rough representation of the selectors and not-at-all "smart".1288786143392363

Oops.. I mis-read the description. That .selector property... People need to be made to understand that it's a very rough representation of the selectors that were used and not-at-all "smart".

Changed November 03, 2010 04:26PM UTC by SlexAxton comment:8

resolution: → invalid
status: openclosed

OK. I think I see what these guys are pointing out. The .selector property is not actually used for the selection, so it's not a good determination of jQuery's support for comma delimited selectors in the 'find' method. In fact, the selection should work just fine (as seen in boushley's fiddle), but the .selector property is just the two selectors concatenated together. It shouldn't be used for testing the final selector that is used.


(Thanks cowboy and boushley)

Changed November 03, 2010 06:10PM UTC by dmethvin comment:9

A couple of points here. One, it's not valid to use a .live() selector after a .find().

DOM traversal methods are not fully supported for finding elements to send to .live(). Rather, the .live() method should always be called directly after a selector, as in the example above. --

Two, the .selector property is not publicly documented. Don't look at it!

Changed September 07, 2011 10:51PM UTC by dmethvin comment:10

#10224 is a duplicate of this ticket.