Side navigation
#10017 closed bug (fixed)
Opened August 10, 2011 08:16PM UTC
Closed May 28, 2012 05:34PM UTC
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: | ||
| Blocked by: | Blocking: |
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.
Attachments (0)
Change History (3)
Changed August 10, 2011 08:36PM UTC by comment:1
Changed August 18, 2011 04:31PM UTC by comment:2
| component: | unfiled → selector |
|---|---|
| priority: | undecided → low |
| status: | new → open |
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.)
Changed May 28, 2012 05:34PM UTC by comment:3
| milestone: | None → 1.7 |
|---|---|
| resolution: | → fixed |
| status: | open → closed |
This has already been fixed. Sizzle uses jQuery's attribute logic.
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.