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
Created attachment 273267 [details] Patch
Comment on attachment 273267 [details] Patch Clearing flags on attachment: 273267 Committed r197726: <http://trac.webkit.org/changeset/197726>
All reviewed patches have been landed. Closing bug.
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.
(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.