Stop clamping HTMLElement.tabIndex to the range of a short

• Component: DOM
• Status: RESOLVED FIXED

[Chris Dumez]

Stop clamping HTMLElement.tabIndex to the range of a short. We apparently did this to match Firefox. However, this no longer matches Firefox's behavior nor the HTML specification:
- https://html.spec.whatwg.org/multipage/interaction.html#dom-tabindex

[Chris Dumez]

Created attachment 273267 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 273267 [details]
Patch

Clearing flags on attachment: 273267

Committed r197726: <http://trac.webkit.org/changeset/197726>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Darin Adler]

Comment on attachment 273267 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=273267&action=review

> Source/WebCore/page/FocusController.cpp:493
> -    int winningTabIndex = std::numeric_limits<short>::max() + 1;
> +    int winningTabIndex = std::numeric_limits<int>::max();

The behavior for an item with a tab index of 2^32-1 is not the same as the old behavior for an item with a tab index of 2^16-1. We will skip such an item instead of returning it as the next element. I suggest constructing a test case that shows this and fixing the bug if it’s a bug.

[Chris Dumez]

(In reply to comment #4)
> Comment on attachment 273267 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=273267&action=review
> 
> > Source/WebCore/page/FocusController.cpp:493
> > -    int winningTabIndex = std::numeric_limits<short>::max() + 1;
> > +    int winningTabIndex = std::numeric_limits<int>::max();
> 
> The behavior for an item with a tab index of 2^32-1 is not the same as the
> old behavior for an item with a tab index of 2^16-1. We will skip such an
> item instead of returning it as the next element. I suggest constructing a
> test case that shows this and fixing the bug if it’s a bug.

Thanks for catching this, I will fix in https://bugs.webkit.org/show_bug.cgi?id=155215.