Input tabbing, focus and tabindex bug. See testcase.

RESOLVED FIXED

Status

()

Firefox
Keyboard Navigation
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: Alexander S., Unassigned)

Tracking

3.5 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.7) Gecko/2009021906 Firefox/3.0.7

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
    <head>
        <title>Firefox Tab Test</title>
        <meta http-equiv="content-type" content="text/html; charset=utf-8">
        <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js"></script>
        
        <!-- 
          
          Steps to reproduce:
          
          1. Click/focus on the firstname input field.
          2. Press tab to move to the lastname input field.
          3. Instead of moving to the lastname field the focus is moved to the submit button in the first form.
          4. Bug reproduced (unless this is the desired behaviour).
          
          Notes
          
          I haven't been able to reproduce this in Safari, thus my conclusion is that it's a bug.
          That assumption might be wrong though, perhaps this is a desired behaviour.
            
        -->
        
    </head>
    <body>
        
        <p></p><p></p>
        
        <form action="">
            <p><input type="text" id="search-query" tabindex="10"> <button type="submit">Search</button></p>
        </form>
        
        <p></p><p></p>
        
        <form action="">
            <p><label>Name</label> <input type="text" id="firstname"> <input type="text" id="lastname"></p>
            
            <p></p><p></p>
            
            <p><label>Email</label> <input type="text"></p>
        </form>
        
        <p></p>
        <p><a href="http://validator.w3.org/check?uri=referer">Markup is valid</a></p>

        
        <script type="text/javascript" charset="utf-8">
            $('#search-query').focus();
        </script>
        
    </body>
</html>



Reproducible: Always

Steps to Reproduce:
. Click/focus on the firstname input field.
          2. Press tab to move to the lastname input field.
          3. Instead of moving to the lastname field the focus is moved to the submit button in the first form.
Actual Results:  
Focus on <button type="submit">Search</button>

Expected Results:  
Focus on <input id="lastname">

Testcase: http://paste.pocoo.org/show/107428/
Confirmed on Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b4pre) Gecko/20090310 Shiretoko/3.1b4pre (.NET CLR 3.5.30729)

Additional details: removing tabindex="10" from the first input box causes the problem to go away. Also, for some reason, focus only shifts to the submit button the first time that you tab away from the input box in the second form. If you try clicking on the input box in the second form and tabbing away again, focus shifts to the next input box in that form. Refreshing the page "resets" it and will cause focus to shift to the submit button again.

This seems to be a bug since the default tabulator order should match the visual sequence of elements (should it not?). 

I also tested in IE7, Safari 3.2.1, and Opera 9.64 (all on Windows Vista). In those browsers, unlike Firefox, the tabulator order correctly matches the visual sequence.

Note to bug submitter: you can include HTML files as attachments.
Created attachment 367100 [details] [diff] [review]
Possible patch

nsEventStateManager keeps track of the tabindex of the current element (in a variable named mCurrentTabIndex). mCurrentTabIndex is initialized to a default of 0, and it is changed when the user focuses on an element with an explicit tabindex value. The problem happens when the user performs this sequence of actions:

1. The user clicks on an element with an explicit tabindex (e.g. tabindex="10" in the testcase provided above). mCurrentTabIndex changes from the default value of 0 to 10.

2.  The user clicks on an element with no explicit tabindex. mCurrentTabIndex does not change.

3. The user presses <tab>. Because mCurrentTabIndex is set to 10, the focus shifts to the element that comes after the element with tabindex=10, as if the element with tabindex=10 was still the current element.

The solution is to make sure mCurrentTabIndex gets reset to its default of 0 when the user clicks on an element with no explicit tabindex.
Attachment #367100 - Flags: review?

Updated

9 years ago
Attachment #367100 - Flags: review? → review?(jst)
(Reporter)

Comment 3

9 years ago
Thanks for finding a likely solution and patch.
(Reporter)

Updated

9 years ago
OS: Mac OS X → All
Hardware: x86 → All
Version: unspecified → 3.1 Branch
Comment on attachment 367100 [details] [diff] [review]
Possible patch

Smaug, I think you'd be a better person to look at this one.
Attachment #367100 - Flags: review?(jst) → review?(Olli.Pettay)

Comment 5

9 years ago
Comment on attachment 367100 [details] [diff] [review]
Possible patch

This needs a mochitest. I'll review/superreview after that is done.

Some tab test examples
http://mxr.mozilla.org/mozilla-central/source/content/events/test/test_bug238987.html?force=1
Especially, remember that tabfocus has different value on OSX than on other platforms.
Attachment #367100 - Flags: review?(Olli.Pettay) → review-

Comment 6

9 years ago
This should be fixed by bug 178324.
Depends on: 178324

Comment 7

9 years ago
This bug should have been fixed by 178324.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.