RESOLVED CONFIGURATION CHANGED 42765
element.tabIndex returns 0 for <frameset> and <legend> elements
https://bugs.webkit.org/show_bug.cgi?id=42765
Summary element.tabIndex returns 0 for <frameset> and <legend> elements
Richard Barrell
Reported 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 ).
Attachments
Tiny web page with javascript that queries the tabindexes of fieldset and legend elements. (1.16 KB, text/html)
2010-07-21 09:51 PDT, Richard Barrell
no flags
Safari 15.5 matches other browsers (except one case differs from Chrome) (768.60 KB, image/png)
2022-06-02 11:35 PDT, Ahmad Saleem
no flags
Richard Barrell
Comment 1 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.
Ahmad Saleem
Comment 2 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.
Ryosuke Niwa
Comment 3 2022-06-30 13:49:56 PDT
Gecko & WebKit behave correctly here.
Note You need to log in before you can comment on or make changes to this bug.