Bug Tracker

Ticket #10017 (closed bug: fixed)

Opened 3 years ago

Last modified 3 years ago

Inconsistent behavior with :selected and [selected] when using filter, not

Reported by: jamietre Owned by:
Priority: low Milestone: 1.7
Component: selector Version: 1.6.2
Keywords: Cc:
Blocking: Blocked by:

Description

 http://jsfiddle.net/jamietre/PNWzg/5/

This bug exists in version of jQuery available on jsFiddle later than 1.2.6. It works in 1.2.6.

It also works in Internet Explorer <8. IE8 proper doesn't work, but in a different way: 'option[selected]' returns no results. IE9, Firefox, Chrome all return the same wrong results.

NOTE: I am not actually sure what the correct behavior should be for [selected] vs. :selected. However, regardless of whether they should return the same elements, there is still a bug, since the results are not consistent depending on the way in which the selectors are used (regular selector, filter, not).

Explanation of the problem: From the fiddle above, tests 1 and 2 return different results, yet tests 6 and 7, using the same selectors except with "filter" for the 2nd clause, return different resutls.

Additionally, tests 4 and 5 return the same results when excluding the same selectors as 1 and 2.

So either ":selected" and "[selected]" should return the same results, or alternatively, they should be consistent in what they return regardless of context.

if "[selected]" is only supposed to return items with a true "selected" attribute, versus things that are considered "selected", then it's not working when used in "filter" and "not" - it behaves the same as ":selected". If it is supposed to return the same thing, then it's not working in the normal selector.

Change History

comment:1 Changed 3 years ago by jamietre

By the way I believe the test on line 246 of test/unit/Traversing.js is wrong:

same( jQuery("#form option").not("option.emptyopt:contains('Nothing'

[selected],[value='1']").get(), q("option1c", "option1d", "option2c",

"option3d", "option3e", "option4e","option5b"), "not('complex selector')");

This test expects option5a to be excluded. However option 5a does not have the "selected" attribute. It is considered "selected" only because it is the first option in a group.

If this is the correct behavior for [selected] then it doesn't work the same way when used as a regular selector, e.g. $('option[selected]') does NOT select "option5a", even though [selected] is excluding it in this test.

It seems that querySelectAll does not match the first option in an option group with [selected], but sizzle does. I expect sizzle should treat this the same way as browsers.

comment:2 Changed 3 years ago by dmethvin

  • Priority changed from undecided to low
  • Status changed from new to open
  • Component changed from unfiled to selector

Agreed on all points, this is the problem of :selected going through the JavaScript path of Sizzle and looking a properties, whereas [selected] goes through the querySelectorAll path and looks at attributes. (Unless there is some other non-qSA selector in the string, such as [selected]:first.)

comment:3 Changed 3 years ago by timmywil

  • Status changed from open to closed
  • Resolution set to fixed
  • Milestone changed from None to 1.7

This has already been fixed. Sizzle uses jQuery's attribute logic.

Note: See TracTickets for help on using tickets.