Version: kdeaddons-konqueror-3.0.3-0.7.i386.rpm (using KDE KDE 3.0.3) Installed from: RedHat RPMs OS: Linux Setting tabindex to -1 should remove the element from the tab cycle. Apparently this doesn't work for the last element with tabindex set to -1. Here is a test case: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"> <html> <head> <title>tabindex.html</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <meta name="GENERATOR" content="Quanta Plus"> </head> <body> <a href="http://bogus.com/link1.html" tabindex="3">link1</a><br> <a href="http://bogus.com/link2.html" tabindex="2">link2</a><br> <a href="http://bogus.com/link3.html" tabindex="1">link3</a><br> <a href="http://bogus.com/link4.html" tabindex="-1">link4</a><br> <form action="script.php" method="POST"> <input type="submit" value="submit1" tabindex="6"><br> <input type="submit" value="submit2" tabindex="5"><br> <input type="submit" value="submit3" tabindex="4"><br> <input type="submit" value="submit4" tabindex="-1"><br> </form> </body> </html> When I tab through the HTML above, the "link4" anchor gets skipped (as it should), but the "submit4" button does not (the bug). If I remove all the submit buttons, "link4" does NOT get skipped (the bug again).
Created attachment 1794 [details] testcase confirmed with testcase.
What makes you think that setting it to -1 should behave that way? http://www.w3.org/TR/REC-html40/interact/forms.html#adef-tabindex does not specify it.
Replaced osaru_online@hotmail.com with maksim@kde.org due to bounces by reporter
Kai, can you answer #2, since the original reporter has went to /dev/null? The best I can think of is that -1 should be treated as 0/no property (right now it gets truncated to 32767)
well, there is no definition for that '-1'... So the bug is other way around: we ignore the 'link4', which should be reached after the elements with a valid tabindex.
hmm, the tab index is taken twice
Is this bug still present in a recent version of KDE, such as 3.5.8 or KDE 4.0 RC 2?
Can confirm for 3.5.8. fredrikh confirms for 4.
This appears to be fixed on svn trunk r793457.
Still present in 3.5.9, fixed in trunk r793457.
reopening as still present in 3.5.9.
Qualifies for backporting to the 3.x branch.