Bug Tracker

Modify

Ticket #12303 (closed bug: fixed)

Opened 20 months ago

Last modified 19 months ago

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

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

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:

Change History

comment:1 Changed 20 months ago by sindresorhus

  • Priority changed from undecided to low
  • Resolution set to invalid
  • Status changed from new to closed
  • Component changed from unfiled to selector

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.

comment:2 Changed 20 months ago by nikolay.r.rusev@…

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:
.

comment:3 Changed 20 months ago by gibson042

  • Priority changed from low to high
  • Status changed from closed to reopened
  • Resolution invalid deleted
  • Milestone changed from None to 1.8.1

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

comment:4 Changed 20 months ago by dmethvin

  • Priority changed from high to blocker
  • Status changed from reopened to open

comment:5 Changed 20 months ago by dmethvin

#12358 is a duplicate of this ticket.

comment:6 Changed 20 months ago by timmywil

  • Owner set to timmywil
  • Status changed from open to assigned

comment:7 Changed 20 months ago by timmywil

  • Owner changed from timmywil to gibson042

comment:8 Changed 20 months ago by timmywil

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

comment:9 Changed 20 months ago by Timmy Willison

  • Status changed from assigned to closed
  • Resolution set to fixed

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

 http://jqbug.com/12303

Changeset: 3a633b0082dbba0365c014ece03d39e8358da18b

comment:10 Changed 19 months ago by nikolay.r.rusev@…

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

comment:11 Changed 19 months ago by timmywil

  • Status changed from closed to reopened
  • Resolution fixed deleted
  • Milestone changed from 1.8.1 to 1.8.2

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.

comment:12 Changed 19 months ago by timmywil

  • Owner changed from gibson042 to timmywil
  • Status changed from reopened to assigned

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.

comment:13 Changed 19 months ago by timmywil

#12527 is a duplicate of this ticket.

comment:14 Changed 19 months ago by dmethvin

#12524 is a duplicate of this ticket.

comment:15 Changed 19 months ago by Timmy Willison

  • Status changed from assigned to closed
  • Resolution set to fixed

Please follow the  bug reporting guidlines and use  jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.

View

Add a comment

Modify Ticket

Action
as closed
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.