Skip to main content

Bug Tracker

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 mikesherov comment:1

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

Changed April 08, 2012 06:33PM UTC by felash@gmail.com comment:2

well, ok then ;)

Changed April 09, 2012 10:43AM UTC by felash@gmail.com 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 rwaldron comment:4

component: unfiledselector
priority: undecidedlow

Changed May 05, 2012 04:20PM UTC by dmethvin comment:5

milestone: None1.next
status: newopen

Changed May 08, 2012 09:11PM UTC by julienw 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 felash@gmail.com 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 felash@gmail.com 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 timmywil comment:9

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.

Changed May 30, 2012 05:25PM UTC by timmywil comment:10

Duplicate of #8473.

Changed May 30, 2012 05:38PM UTC by felash@gmail.com 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 anonymous comment:12

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