Skip to main content

Bug Tracker

Side navigation

#12303 closed bug (fixed)

Opened August 15, 2012 08:09AM UTC

Closed September 19, 2012 03:32PM UTC

Attribute selector fails if the attribute value contains :first :last

Reported by: nikolay.r.rusev@gmail.com Owned by: timmywil
Priority: blocker Milestone: 1.8.2
Component: selector Version: 1.8.0
Keywords: Cc:
Blocked by: Blocking:
Description

Sizzle fails when parsing the following selector:

:input[myattr="value:FirstName"]

It seems like it treats :FirstName as :first pseudo selector. Same can be observed if the value is value:LastName or anything that looks like pseudo selector.

Removing the colon from :input will not trigger the error.

Here are some fiddles demonstrating the scenario:

Attachments (0)
Change History (15)

Changed August 15, 2012 09:39AM UTC by sindresorhus comment:1

component: unfiledselector
priority: undecidedlow
resolution: → invalid
status: newclosed

I'm not sure why that worked in 1.7.1, but it is clearly wrong. You can't combine a pseudo selector with an attribute selector. If you need to select an attribute, then just use an tag and attribute selector like you do in your last jsfiddle.

Also it is deprecated and slow. Use attribute selector instead.

Changed August 15, 2012 10:27AM UTC by nikolay.r.rusev@gmail.com comment:2

'''You can't combine a pseudo selector with an attribute selector.'''

This isn't serious, is it? Where does the documentation states that both cannot be used?

Also it is deprecated and slow.

What is deprecated? Is it documented?

The value for attribute must not be treated as selector, but rather as plain text. Also please note that the behavior is triggered only if there is pseudo selector before the attribute selector. This isn't be normal.

Another example that prove it wrong:

''quoted from the second paragraph''

'''If you wish to use any of the meta-characters ( such as !"#$%&'()*+,./:;<=>?@[\\]^`{|}~ ) as a literal part of a name, you must escape the character with two backslashes: \\\\.'''

Changed August 15, 2012 12:29PM UTC by gibson042 comment:3

milestone: None1.8.1
priority: lowhigh
resolution: invalid
status: closedreopened

No, this is valid. We're erroneously catching :first et. al. inside attribute selectors when we sweep for positional ones.

Changed August 21, 2012 12:41AM UTC by dmethvin comment:4

priority: highblocker
status: reopenedopen

Changed August 21, 2012 01:52AM UTC by dmethvin comment:5

#12358 is a duplicate of this ticket.

Changed August 24, 2012 09:57PM UTC by timmywil comment:6

owner: → timmywil
status: openassigned

Changed August 27, 2012 04:18PM UTC by timmywil comment:7

owner: timmywilgibson042

Changed August 29, 2012 04:47PM UTC by timmywil comment:8

I went ahead and did an implementation for this.

@gibson042: I've created a Sizzle issue for the remaining POS problems here: https://github.com/jquery/sizzle/issues/148

Changed August 29, 2012 04:49PM UTC by Timmy Willison comment:9

resolution: → fixed
status: assignedclosed

Sizzle: POS selectors make more extensive use of tokenization. Fixes #12303.

http://jqbug.com/12303

Changeset: 3a633b0082dbba0365c014ece03d39e8358da18b

Changed September 13, 2012 08:07AM UTC by nikolay.r.rusev@gmail.com comment:10

The fix actually '''doesn't work in jQuery 1.8.1'''.

"''Uncaught RangeError: Maximum call stack size exceeded''" exceptions is thrown. Tested in Chrome(21.0.1180.89 m), FF(15.0.1) and IE9. FF even crash when attempt to execute the query.

Here is an example with v. 1.8.1 http://jsbin.com/ecowez/2/edit

Changed September 13, 2012 02:17PM UTC by timmywil comment:11

milestone: 1.8.11.8.2
resolution: fixed
status: closedreopened

Woopsie. Looks like tokenization was fixed and handlePOS doesn't recognize any part of the selector as POS, but it goes into an infinite loop because the codepath keeps going into handlePOS.

Changed September 13, 2012 02:25PM UTC by timmywil comment:12

owner: gibson042timmywil
status: reopenedassigned

Wow. You might think the tests I added would also go into an infinite loop, but they don't because the regex index for the POS regex is never reset and it returns false on the second check, thus handlePOS is not entered again the second time around. I'm flabbergasted.

Changed September 13, 2012 02:27PM UTC by timmywil comment:13

#12527 is a duplicate of this ticket.

Changed September 14, 2012 12:32AM UTC by dmethvin comment:14

#12524 is a duplicate of this ticket.

Changed September 19, 2012 03:32PM UTC by Timmy Willison comment:15

resolution: → fixed
status: assignedclosed

Update Sizzle: Fixes #12303, #12474, #12523, #12526, #12541.

Changeset: f7980d4d68e76147e6a9ddd7b30d379ddce7f222