Skip to main content

Bug Tracker

Side navigation

#7010 closed bug (fixed)

Opened September 07, 2010 09:07PM UTC

Closed July 03, 2012 02:19AM UTC

:not(:has(:has(*))) fails

Reported by: dept42 Owned by: timmywil
Priority: low Milestone: 1.next
Component: selector Version: 1.4.4
Keywords: Cc:
Blocked by: Blocking:
Description

While :not(:has(*)) works fine to find nodes with no children, and :has(:has(*)) works to find nodes with grandchildren, :not(:has(:has(*))) returns nothing, instead of returning only nodes without grandchildren.

It seems like this may be due to a chunker bug which parses the filter into [":not", ":has(:has(*)))"], which seems wrong (note unbalanced closing paren) -- but I couldn't follow what was happening in the code past that point.

Interestingly, :not(:has(:has(*)) does return something, although not the expected result.

Attachments (0)
Change History (22)

Changed September 08, 2010 12:27AM UTC by dmethvin comment:1

component: unfiledselector

Changed October 15, 2010 02:26AM UTC by snover comment:2

milestone: 1.4.3
priority: → low
status: newopen

Changed October 28, 2010 03:24AM UTC by rwaldron comment:3

owner: → dept42
status: openpending

Please provide a reduced test case on jsFiddle

Changed October 31, 2010 12:48AM UTC by anonymous comment:4

Here is the jsfiddle for this bug. http://jsfiddle.net/9uxcr/ Tested against 1.4.3 and the jquery 0 GIT versions, and the bug still persists.

Changed November 22, 2010 12:28AM UTC by jitter comment:5

milestone: → 1.4.5
priority: lowhigh
status: pendingopen
version: 1.4.21.4.4

test case. :not(:has(:has(*))) throws an exception under 1.4.4 (under 1.4.3 it incorrectly returned an empty set).

Changed July 11, 2011 05:44PM UTC by dmethvin comment:6

status: openpending

Can you come up with a more realistic test case? It does seem like this fails but it seems unlikely that anyone would use it in real life. It's hard to justify spending time on it otherwise.

Changed July 11, 2011 05:52PM UTC by dmethvin comment:7

status: pendingopen

Changed July 11, 2011 05:52PM UTC by dmethvin comment:8

status: openpending

Changed July 11, 2011 06:06PM UTC by dept42 comment:9

status: pendingnew

FWIW, I ran across this bug precisely because I needed to find all nodes without grandchildren in a real application. IIRC, the use case was that I was looking for date information in HTML of variable structure, where sometimes it would be in a leaf node, or sometimes split across a couple adjacent leaf nodes (e.g. because part of it was italicized). So I wanted to get a list of all nodes in the bottom two levels of the hierarchy (those without grandchildren), so that I could then check the text() of each against the date formats I was able to parse.

Changed July 12, 2011 03:45PM UTC by dmethvin comment:10

priority: highlow
resolution: → patchwelcome
status: newclosed

This isn't going to be a priority so we're going to close this patchwelcome. A better way to solve the original problem would be to use filter with a function.

Changed July 12, 2011 04:58PM UTC by john comment:11

#8132 is a duplicate of this ticket.

Changed July 12, 2011 05:00PM UTC by john comment:12

resolution: patchwelcome
status: closedreopened

This seems to be a larger issue - it seems like many bugs are happening related to :has() containing other :foo() expressions.

Changed July 15, 2011 09:12PM UTC by dmethvin comment:13

status: reopenedopen

Changed August 12, 2011 12:10AM UTC by timmywil comment:14

#10020 is a duplicate of this ticket.

Changed August 18, 2011 11:12PM UTC by AlistairB comment:15

Stupid question. Why is a core selector engine bug, effecting all browsers, of which many duplicate bugs have been raised, only a low priority to fix?

More test cases: http://jsfiddle.net/AlistairB/F7gzn/5/

Changed August 19, 2011 04:01AM UTC by dmethvin comment:16

It's low priority because very few people use selectors that complex. It's also hard to fix.

Since these selectors are not part of any standard (they're not CSS3) we might also just define away the non-working cases by restricting the allowed sub-selectors.

Changed August 24, 2011 03:01AM UTC by AlistairB comment:17

Replying to [comment:16 dmethvin]:

It's low priority because very few people use selectors that complex. It's also hard to fix. Since these selectors are not part of any standard (they're not CSS3) we might also just define away the non-working cases by restricting the allowed sub-selectors.

Thanks for your response.

Unfortunately it's a fairly common case in AJAXy web applications IMO.

Say you have a table of people attending an event and you click on the button 'change to female only event'. You want to do something like this.

$(".person-table > tr:has(.sex:contains(man))").each(function() {
    var personId = $(this).children(".person-id").text();

    removePersonFromEventViaAJAX(personId);
    
    $(this).remove();
});

But due to this bug, you are forced to select the .sex cells themselves and traverse from this in the each block. (Not a massive deal, but I think cases like this are relatively common.)

Changed December 10, 2011 07:05PM UTC by dmethvin comment:18

blockedby: → 10697
milestone: 1.next1.8

Changed May 10, 2012 12:33PM UTC by T.J. Crowder <tj@crowdersoftware.com> comment:19

#8132 was closed as a duplicate of this bug, although this one doesn't throw a syntax error (it just returns incorrect results), whereas in #8132, Sizzle actually throws an error. Are we sure the syntax error variant really is a duplicate of this same bug?

If so, another quite simple failing test case -- give me all divs that have a span as their first child:

var elms = $('div:has(span:nth-child(1))');

Result:

Syntax error, unrecognized expression: :has(span:nth-child

Live copy | source

And note that although the syntax error suggests it's a problem with nested parentheses, some other nested parentheses work, such as:

var elms = $('div:has(p:not(.b))');

...works just fine (Live copy | source).

Changed May 28, 2012 04:54PM UTC by timmywil comment:20

Changed June 19, 2012 06:09AM UTC by timmywil comment:21

milestone: 1.81.next
owner: dept42timmywil
status: openassigned

Changed July 03, 2012 02:19AM UTC by timmywil comment:22

resolution: → fixed
status: assignedclosed

Sizzle: fix multiple nested pseudos. Fixes #7010.

Changeset: accb3c4932055692221ba7d21e207680df8017b3