151551 - bad tabulation order if form resets keyboard focus

Status: RESOLVED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[hfastt]

concerning:    Mozilla 1.0.0 release

I use a slow dial-up connection, so sometimes I start filling out a web form 
before the whole page is loaded. If the form resets the keyboard focus with an 
onLoad() event, the tabulation order (jumping between fields with the "Tab" key) 
doesn't take this into account. I.e. if I press the "Tab" key, the cursor jumps 
to the field next to the one before the focus was reset. I'm not sure which 
beaviour is better, but sometimes this looks weird.

Comment 1

[Aaron Leventhal]

What do other browsers do in this situation?

Comment 2

[Aaron Leventhal]

Actually, I'm not 100% I understand your bug report exactly.

Could you supply a sample URL, and explain again?

Tabstop 1
Tabstop 2
Tabstop 3
Tabstop 4
.
.
Tabstop 99 (onload focuses here)
Tabstop 100
.
.

So you press Tab a couple of times, and get to tabstop 2.
Then the onload fires and you get to "Tabstop 99".
Will the next tabstop bring you to tabstop 3 or tabstop 100?

Comment 3

[hfastt]

I haven't experienced this behaviour a lot of times (most forms don't use onLoad
focus reset), so I can't be 100% certain what exactly it will do in any one
case. According to the behaviour I've deducted, in your example, the next
tabstop will be #3.

Unfortunately, I have only Mozilla and an old IE4 on the computer with the slow
connection. IE4 doesn't reset the focus at all with the pages I test (most
likely doesn't understand the JS). Sorry I can't help with this.

I've noticed this behaviour with http://mail.yahoo.com. If I go to the
"password" field, when the page loads completely, the focus is reset to the
"login" field. If I press <Tab>, the focus goes to the "Remember ID" checkbox.

Comment 4

[Aaron Leventhal]

So it would appear that pressing tab doesn't move from where the focus was reset
to, but from where you were before it was reset.

Comment 5

[hfastt]

yes

Comment 6

[Asa Dotzler [:asa]]

Is this still a problem with Mozilla 1.7 beta or newer?

Comment 7

[hfastt]

I'm sorry, right now I don't have access to a computer with a slow connection.

Comment 8

[Michael Trimm]

using firefox 0.9, i can't get a slow connection right now.

Comment 9

[Micha³ Piaskowski]

Attachment: A form with delayed on focus reset

I created a testcase which resets the focus 5 seconds after the onload event,
so  fast connection shouldn't be a problem any more.

With this testcase it seems to work for me on build 2004120405

Does anybody still see this?

Comment 10

[Sabrina Curtis]

I think I may have spyware, because my system has been acting slower than usual,
and I cannot seem to get rid of it

Comment 11

[Eugene Kim]

The bug is not reproducible on build ID 2005010906.

Comment 12

[Aaron Leventhal]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041220