Pressing tab from the password field does not set focus to the remember me checkbox, instead focus jumps to the submit button.

Comments

nickl’s picture

Status: Active » Fixed

Added tabindex attributes to form elements in form alter when adding the checkbox.

    $form['name']['#attributes']['tabindex'] = '1';
    $form['pass']['#attributes']['tabindex'] = '2';
    $form['remember_me']['#attributes']['tabindex'] = '3';
    $form['submit']['#attributes']['tabindex'] = '4';
Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

donquixote’s picture

Status: Closed (fixed) » Active

Sorry, but this does not solve the problem.

You need to consider that an average page can have a lot more form elements, all with no explicit tabindex (and other interactive elements such as links etc). Thus, the browser will jump to all the other form elements, before it finally gets to the password field.

I think the only safe solution is to change the order of the fields in html.

donquixote’s picture

See also
http://drupal.org/node/665982#comment-3560662
("hint" module).

There could be other tabindex side effects in combination with "hint", but this one is definitely an issue for remember_me.

nickl’s picture

Version: master » 6.x-2.x-dev
Status: Active » Postponed (maintainer needs more info)

Please provide detailed scenario to reproduce this problem.
Is this still an issue?

The fields are properly ordered in html with he correct tabindex and works in every scenario I have tried.

<div><div class="form-item" id="edit-name-wrapper"> 
 <label for="edit-name">Username: <span class="form-required" title="This field is required.">*</span></label> 
 <input type="text" maxlength="60" name="name" id="edit-name" size="15" value="" tabindex="1" class="form-text required" /> 
</div> 
<div class="form-item" id="edit-pass-wrapper"> 
 <label for="edit-pass">Password: <span class="form-required" title="This field is required.">*</span></label> 
 <input type="password" name="pass" id="edit-pass"  maxlength="60"  size="15"  tabindex="2" class="form-text required" /> 
</div> 
<div class="form-item" id="edit-remember-me-wrapper"> 
 <label class="option" for="edit-remember-me"><input type="checkbox" name="remember_me" id="edit-remember-me" value="1"  checked="checked"  tabindex="3" class="form-checkbox" /> Remember me</label> 
</div> 
<input type="submit" name="op" id="edit-submit" value="Log in"  tabindex="4" class="form-submit" /> 

Please provide more info.

donquixote’s picture

Status: Postponed (maintainer needs more info) » Active

Sorry, this is quite long ago now :(

I suppose, by looking at the code, if anything else on the page has a tabindex of 2 or 3 (or in some cases, 1 or 4), then this other element will sneak into the sequence.

E.g. if another element further down in the html has tabindex 2, this would result in this tab sequence:

username
password
other field with tabindex 2
remember me checkbox
submit

To avoid that, you could try giving all those items the same tab index. Such as, tabindex="1" for each of them. They would still be tabbed in the sequence that they are supposed to, because that's the order in html. No other element will get in between.

nickl’s picture

Status: Active » Fixed

It could then also be possible somehow that another element with index 1 catches the tab order.

Changed the tabindex to be 99991 through 99994 to prevent any other field to likely have the same index.

donquixote’s picture

Status: Fixed » Needs work

If another element has index 1, it will be tabbed either before or after the other inputs, because it is either before or after these in the DOM. To be in between, it would have to be in between in the DOM.
Or do I miss something?

<input type="text" value="Before" tabindex="1" />
<div><div class="form-item" id="edit-name-wrapper"> 
 <label for="edit-name">Username: <span class="form-required" title="This field is required.">*</span></label> 
 <input type="text" maxlength="60" name="name" id="edit-name" size="15" value="" tabindex="1" class="form-text required" /> 
</div> 
<div class="form-item" id="edit-pass-wrapper"> 
 <label for="edit-pass">Password: <span class="form-required" title="This field is required.">*</span></label> 
 <input type="password" name="pass" id="edit-pass"  maxlength="60"  size="15"  tabindex="1" class="form-text required" /> 
</div> 
<div class="form-item" id="edit-remember-me-wrapper"> 
 <label class="option" for="edit-remember-me"><input type="checkbox" name="remember_me" id="edit-remember-me" value="1"  checked="checked"  tabindex="1" class="form-checkbox" /> Remember me</label> 
</div> 
<input type="submit" name="op" id="edit-submit" value="Log in"  tabindex="1" class="form-submit" />
<input type="text" value="After" tabindex="1" />

(I set this to needs work, because I am not sure it is being read otherwise)

nickl’s picture

Status: Needs work » Fixed

set back to fixed as the solution at hand still solves the problem.
Feel free to roll a patch to the contrary with your test results at hand.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

nickl’s picture

Status: Closed (fixed) » Needs work

We must've posted simultaneously, I din't see this post or was it a reply like I am doing now.

To get back to your comments, it does make sense what you are saying, have you tested that? We originally tried at length to place the field in between the password field and submit button. It might have been that drupal_render added a tab index before it came to hook_form_alter and we needed to rectify that. Conflicting with other fields having the same index will be hard to rectify, but I will open the issue again.

nickl’s picture

Version: 6.x-2.x-dev » 7.x-1.0-rc2
Status: Needs work » Fixed

I tried your theory and it happened o work quite well! Being on tabindex 1 also prompts the browser to tabe to user name first.

I wasn't happy with how the sorting was done either so I wrote that over and reduced the code by two files and a folder.

I will be porting it to D6 soon, marking the d7 version fixed. Thank you for your patience and motivation.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

frosty29’s picture

Version: 7.x-1.0-rc2 » 6.x-2.3
Status: Closed (fixed) » Needs work

I didn't knowingly have problems before, but the latest version of remember_me with the high tabindex (#7) does not work for me in IE9 (fine in FF & Chrome).
In my case, tabbing from Username skips down past password, remember me and Login button to Request new password!
I imagine IE can't handle such big numbers. I modifed module to have this:
$form['name']['#attributes']['tabindex'] = '201';
$form['pass']['#attributes']['tabindex'] = '202';
$form['remember_me']['#attributes']['tabindex'] = '203';
$form['submit']['#attributes']['tabindex'] = '204';

and now all is well in IE as well.

nickl’s picture

Status: Needs work » Patch (to be ported)

It seems I haven't pushed the 6.x branch of the fix, there obviously was a reason for that so I will do some tests again before I commit.

The eventual fix was to change them all to 1 and not sequential, please give that a try to see how ie chokes on that. The problem with sequential tab indexes were that other elements might, using you numbers as example, also be indexed 201,202,203, etc. which will cause the tab action to jump to those fields first before continuing. By making them all 1 they are the first on the list and then appears to follow the natural order. .

sbozhko’s picture

According to MSDN page (http://msdn.microsoft.com/en-us/library/ms534654(v=vs.85).aspx) maximum value of tabindex is 32767. Therefore now it does not work in IE.

nickl’s picture

Version: 6.x-2.3 » 6.x-2.4

You will be much better off with the back port of the 7.x module version 6.x.2.4

nickl’s picture

Status: Patch (to be ported) » Closed (fixed)
nickl’s picture

Status: Closed (fixed) » Fixed

My finger slipped

frosty29’s picture

Thanks for new version, solves tab order in my three usual browsers.
;-)

nickl’s picture

My pleasure! Apologies for the frustrations don't know why the back port didn't go live with the 7.x version, this was solved weeks ago.

I think that wraps us up till D8, wishful thinking.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.