996095 - Tabindex ignored when it's not in the int16_t range

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Nick]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20140314220517

Steps to reproduce:

Create elements (input or anchor) with a tabindex greater than 40000 and when tabbing through fields starting from the first, these elements are ignored and focus is never brought to them.  See fiddle below:

http://jsfiddle.net/tatesn/hVv72/




Actual results:

Focus eventually ended up on the tab in the window, then moved around all elements outside the webpage, and never landed on the inputs with the large tabindex value. 


Expected results:

As in other browsers, when tabbing from one field to the next, even if the tabindex is reasonably large, the element should receive focus when tabbed from the next lowest tabindex.

Comment 1

[Boris Zbarsky [:bzbarsky]]

One issue here is in nsGenericHTMLElement::ParseAttribute:

992     if (aAttribute == nsGkAtoms::tabindex) {
993       return aResult.ParseIntWithBounds(aValue, -32768, 32767);
994     }

That code has been in place since the original fix for bug 171366.

But then nsFocusManager::GetNextTabIndex gets the string value of the attribute and re-parses as an integer, so the node has 32767 stored, but we're looking for a node with 40000, and we find no match.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Attachment: All 32-bit integers are valid values for tabindex; don't restrict it to the int16_t range during parsing

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8424916 [details] [diff] [review]
All 32-bit integers are valid values for tabindex; don't restrict it to the int16_t range during parsing

Huh, the old limitation is odd.

Comment 4

[Boris Zbarsky [:bzbarsky]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/3602db87fac3

Comment 5

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/3602db87fac3

Comment 6

[kenkon]

[bugday-20140820]

Reproduced on:
Firefox 31.0

Verified on:
Firefox 32.0 Beta 8 (20140818191513)
Nightly 34.0a1 (20140820030202)

Comment 7

[alex_mayorga]

Verifying per comment 6.

Comment 8

[kenkon]

[testday-20140912]

Just for completeness, verified also on Firefox 33.0 beta 3.

Comment 9

[Camelia Badau [:cbadau], Desktop Test Engineering]

Marking verified on Firefox 33 based on comment #8.