Side navigation
#11273 closed bug (cantfix)
Opened February 02, 2012 04:07PM UTC
Closed February 04, 2012 03:06PM UTC
Last modified February 04, 2012 03:21PM UTC
Indeterminate checkboxes not matched with :checked selector in WebKit browsers
Reported by: | lowbatteries | Owned by: | |
---|---|---|---|
Priority: | low | Milestone: | None |
Component: | selector | Version: | 1.7.1 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
If a checkbox is checked, but then has the indeterminate property set, it will not be matched with the :checked selector (even though it is still checked, and would be posted with a form submission).
Reduced case here: http://jsfiddle.net/7TcKF/3/
This seems to boil down to .webkitMatchesSelector(':checked') which has the same incorrect behavior.
The issue does not appear in jQuery 1.2.6 or 1.3.2, but seems to have been introduced in 1.4.4 and onwards.
I confirmed the erronous behavior in Chrome 16, Chrome 18 (Canary), Safari 5.1.2, and WebKit nightly. This bug does not show up in Opera, IE6+, or Firefox.
Attachments (0)
Change History (4)
Changed February 02, 2012 04:16PM UTC by comment:1
Changed February 04, 2012 03:06PM UTC by comment:3
resolution: | → cantfix |
---|---|
status: | new → closed |
This bug should be reported to Webkit, we don't have an effective way to fix it within jQuery.
Changed February 04, 2012 03:21PM UTC by comment:4
component: | unfiled → selector |
---|---|
priority: | undecided → low |
May be related to this Chrome ticket, which from a rendering standpoint makes an indeterminate checkbox always appear to be unchecked: http://code.google.com/p/chromium/issues/detail?id=73233
The spec says
indeterminate
should only affect visual rendering so I agree this is a bug, but this seems like a Chrome qSA bug to me. We don't have a generalized way to work around it short of looking for ":checked" anywhere in the selector string and sending it down the Sizzle JavaScript path, which is a pretty cruel thing to do performance-wise for such a rare edge case.