Bug Tracker

Modify

Ticket #10017 (closed bug: fixed)

Opened 3 years ago

Last modified 23 months 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 23 months 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.

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.