Bug Tracker

Opened 11 years ago

Closed 11 years ago

Last modified 10 years ago

#11568 closed bug (duplicate)

unreliable behaviour with selecting tabIndex with attributes selectors

Reported by: [email protected] Owned by:
Priority: low Milestone: 1.next
Component: selector Version: 1.7.2
Keywords: Cc:
Blocked by: Blocking:


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.


Change History (12)

comment:1 Changed 11 years ago by mikesherov

It's impossible for this to be fixed before 1.8... 1.8 is the next version. :)

comment:2 Changed 11 years ago by [email protected]

well, ok then ;)

comment:3 Changed 11 years ago by [email protected]

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...

comment:4 Changed 11 years ago by Rick Waldron

Component: unfiledselector
Priority: undecidedlow

comment:5 Changed 11 years ago by dmethvin

Milestone: None1.next
Status: newopen

comment:6 Changed 11 years ago by julienw

in your jsfiddle, the "[tabindex=0]" is missing, which exhibits the problem in QSA-supporting browsers as well.

comment:7 Changed 11 years ago by [email protected]

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.

comment:8 Changed 11 years ago by [email protected]

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 ) :

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.

comment:9 Changed 11 years ago by timmywil

Resolution: duplicate
Status: openclosed

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.

comment:10 Changed 11 years ago by timmywil

Duplicate of #8473.

comment:11 Changed 11 years ago by [email protected]

you need to use the attrHooks I wrote before as otherwise I think that this won't work in older IE.

comment:12 Changed 10 years ago by anonymous

It works for me in 1.8.0. Tried in IE7 and Firefox 16. Thanks.

Note: See TracTickets for help on using tickets.