Side navigation
#11568 closed bug (duplicate)
Opened April 08, 2012 05:21PM UTC
Closed May 30, 2012 05:25PM UTC
Last modified August 10, 2012 11:18PM UTC
unreliable behaviour with selecting tabIndex with attributes selectors
| Reported by: | felash@gmail.com | Owned by: | |
|---|---|---|---|
| Priority: | low | Milestone: | 1.next |
| Component: | selector | Version: | 1.7.2 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
I found that using [tabIndex] or [tabIndex=0] or [tabIndex='0'] as selectors yield unreliable results.
I made a jsfiddle there : http://jsfiddle.net/RRktv/2/
As I understand, using [tabIndex=0] triggers the Sizzle search, where as the other forms trigger using querySelectorAll if available. Therefore, you can use IE7 or IE8/9 in IE7 mode to always use the Sizzle search.
It seems related to ticket #8473 (and maybe also to ticket #11413 which was invalidly marked invalid IMHO).
This is especially problematic in IE6/7 because then we can't get those nodes with the tabIndex attribute especially set.
Also, this means the result for this selector is not consistent across browsers AND across two valid but different invocations in the same browser (ie tabIndex=0 and tabIndex='0')
Therefore, I think it should be fixed earlier than what you're suggesting in ticket #8473.
Thanks
Attachments (0)
Change History (12)
Changed April 08, 2012 06:32PM UTC by comment:1
Changed April 08, 2012 06:33PM UTC by comment:2
well, ok then ;)
Changed April 09, 2012 10:43AM UTC by comment:3
I'd like to add that it seems ok to me that jQuery keeps its attrHooks for tabIndex. However, what seems wrong is that jQuery uses these hookes to match the attribute selector.
But I understand this could be difficult to change this now...
Changed April 23, 2012 04:18PM UTC by comment:4
| component: | unfiled → selector |
|---|---|
| priority: | undecided → low |
Further reduction http://jsfiddle.net/rwaldron/RRktv/4/
Changed May 05, 2012 04:20PM UTC by comment:5
| milestone: | None → 1.next |
|---|---|
| status: | new → open |
Changed May 08, 2012 09:11PM UTC by comment:6
in your jsfiddle, the "[tabindex=0]" is missing, which exhibits the problem in QSA-supporting browsers as well.
Changed May 08, 2012 10:20PM UTC by comment:7
I'm not sure of what I said about IE6/7 in my initial report, as I think I was testing with jQuery 1.6.2.
However the issue is still here in jQuery 1.7.2 but it is less important for me than I thought initially.
Changed May 11, 2012 07:31AM UTC by comment:8
I tried to replace the tabindex attrHooks get function by :
function( elem ) {
// elem.tabIndex doesn't always return the correct value when it hasn't been explicitly set
// http://fluidproject.org/blog/2008/01/09/getting-setting-and-removing-tabindex-values-with-javascript/
var attributeNode = elem.getAttributeNode("tabindex");
return attributeNode && attributeNode.specified ?
parseInt( attributeNode.value, 10 ) :
undefined;
};
and it seems to work.
(I did this inside the jsfiddle with cd(frames[0]) in Firebug).
Differences to the propHooks similar function: we don't try to infer the tabindex from the type of the element.
Changed May 30, 2012 05:25PM UTC by comment:9
| resolution: | → duplicate |
|---|---|
| status: | open → closed |
Closing as duplicate. It is the same bug from a different perspective. QSA throws an error when you don't quote the attribute value, as it should. We compensate for this, but that means it will follow Sizzle's attribute codepath, which is the reason for the inconsistency. We will be removing the tabindex attrHook to make it consistent.
Changed May 30, 2012 05:25PM UTC by comment:10
Duplicate of #8473.
Changed May 30, 2012 05:38PM UTC by comment:11
you need to use the attrHooks I wrote before as otherwise I think that this won't work in older IE.
Changed August 10, 2012 11:18PM UTC by comment:12
It works for me in 1.8.0. Tried in IE7 and Firefox 16. Thanks.
It's impossible for this to be fixed before 1.8... 1.8 is the next version. :)