Pressing tab from the password field does not set focus to the remember me checkbox, instead focus jumps to the submit button.
Pressing tab from the password field does not set focus to the remember me checkbox, instead focus jumps to the submit button.
Comments
Comment #1
nickl commentedAdded tabindex attributes to form elements in form alter when adding the checkbox.
Comment #2
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.
Comment #3
donquixote commentedSorry, 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.
Comment #4
donquixote commentedSee 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.
Comment #5
nickl commentedPlease 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.
Please provide more info.
Comment #6
donquixote commentedSorry, 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.
Comment #7
nickl commentedIt 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.
Comment #8
donquixote commentedIf 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?
(I set this to needs work, because I am not sure it is being read otherwise)
Comment #9
nickl commentedset 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.
Comment #11
nickl commentedWe 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.
Comment #12
nickl commentedI 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.
Comment #14
frosty29 commentedI 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.
Comment #15
nickl commentedIt 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. .
Comment #16
sbozhko commentedAccording 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.
Comment #17
nickl commentedYou will be much better off with the back port of the 7.x module version 6.x.2.4
Comment #18
nickl commentedComment #19
nickl commentedMy finger slipped
Comment #20
frosty29 commentedThanks for new version, solves tab order in my three usual browsers.
;-)
Comment #21
nickl commentedMy 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.