Bug 42765

Summary: element.tabIndex returns 0 for <frameset> and <legend> elements
Product: WebKit Reporter: Richard Barrell <robarrell>
Component: DOMAssignee: Nobody <webkit-unassigned>
Status: RESOLVED CONFIGURATION CHANGED    
Severity: Normal CC: ahmad.saleem792, ap, cdumez, rniwa, tyler_w
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: All   
Attachments:
Description Flags
Tiny web page with javascript that queries the tabindexes of fieldset and legend elements.
none
Safari 15.5 matches other browsers (except one case differs from Chrome) none

Description Richard Barrell 2010-07-21 09:51:22 PDT
Created attachment 62200 [details]
Tiny web page with javascript that queries the tabindexes of fieldset and legend elements.

SUMMARY
element.tabIndex returns 0 for <frameset> and <legend> elements, but it should return -1.

STEPS
1. View the attached web page, tabindex.html, with javascript turned on.

RESULTS
Different browsers exhibit a glorious cornucopia of different results on this page. I've grouped them as follows:
Firefox and Opera (I have tested Firefox 3.6.6 on Linux, Firefox 3.0 on Linux via Wine, Firefox 3.5.9 on Windows and Opera 9.64 on Windows) return:
frameset tabindex = -1
legend tabindex = -1
default focus:
activeElement nodeName = BODY
after frameset.focus():
activeElement nodeName = BODY
after legend.focus():
activeElement nodeName = INPUT
after input.focus():
activeElement nodeName = INPUT

Internet Explorer (I have tested Internet Explorer 6.0.2800.1106, Internet Explorer 6, 7 and 8 using IETester 0.44, and Internet Explorer 8.0.6001.18813) return:
frameset tabindex = 0
legend tabindex = 0
default focus:
activeElement nodeName = BODY
after frameset.focus():
activeElement nodeName = FIELDSET
after legend.focus():
activeElement nodeName = FIELDSET
after input.focus():
activeElement nodeName = INPUT

Webkit browsers (I have tested Chromium r53140 on Linux, in GtkLauncher from Webkit r63640 on Linux, Google Chrome 5.0.375.99 on Windows and Apple Safari 4.0.2 on Windows) return:
frameset tabindex = 0
legend tabindex = 0
default focus:
activeElement nodeName = BODY
after frameset.focus():
activeElement nodeName = BODY
after legend.focus():
activeElement nodeName = INPUT
after input.focus():
activeElement nodeName = INPUT

WHY THIS IS A BUG
Some javascript WYSIWYGs used in the wild (for example, CKEditor - see CKEDITOR.dom.element.prototype.focusNext in http://svn.ckeditor.com/CKEditor/tags/3.3.1/_source/plugins/tab/plugin.js and getTabIndex in http://svn.ckeditor.com/CKEditor/tags/3.3.1/_source/core/dom/element.js) use DOM nodes' tabIndex attribute to decide which elements should appear in normal tab order, and hence can have their .focus() method called in order to highlight them.

In Gecko, this method works without a hitch because 0 is only returned for the tabIndex of objects that can be focused on.
However, in Webkit browsers, the .focus() method of <fieldset> and <legend> elements does nothing, and they do not appear in the normal tab order, despite the fact that their tabIndexes both appear to be 0. This can cause bugs such as being unable to tab forward out of a CKEditor instance if there is a fieldset element after it before the next normally focusable element.
In IE... apparently everybody works around the fact that tabIndex, like most things, is totally broken. (CKEditor for example uses a completely different mechanism for detecting focusable elements in Internet Explorer ).
Comment 1 Richard Barrell 2010-07-21 10:17:44 PDT
Just for reference, I've just dug out the office iPad and tried the same page in Safari on that, and I get the same result as in every other Webkit browser.
Comment 2 Ahmad Saleem 2022-06-02 11:35:09 PDT
Created attachment 459968 [details]
Safari 15.5 matches other browsers (except one case differs from Chrome)

I noted using attached test case that Safari 15.5 on macOS 12.4 matches Firefox Nightly 104 behavior by returning -1 and also shows all activeElements depending on frames and tabIndex returning same. Only difference was for "after legend.focus()" in Chrome, which returned "BODY" different from Safari and Chrome.

Please refer attached screenshots for the updated results. I am not familiar with relevant web spec to identify which is correct behaviour but just wanted to share updated output.
Comment 3 Ryosuke Niwa 2022-06-30 13:49:56 PDT
Gecko & WebKit behave correctly here.