Many sites and many non-web programs require one to log in with a user ID and password.
Is there any good reason (e.g. security, perhaps?) why the cursor would not be automatically placed within the user ID field, ready for you to type? On many of these screens, I have to click with my mouse to get there, which is not a big deal but it is marginally less efficient for me.
So, good reasons, or lazy programming?
Roddy
Mostly the latter. I think if there’s any justification for it, it’s to make bot logins and abuse harder.
OTOH, I love my online banking site. It puts the cursor in first my ID field, then in the password field, no positioning click needed.
But mostly oversight (“Oh… you *want *it to do that?”) and lazy programming, IMVHO.
Not putting the cursor in the User ID field might make it harder for a hacker to attempt to guess a username/password combination. A tool that assumes the cursor would be in the User ID field would misfire when it wasn’t. In that case it would be lazy programming by the hacker.
By cursor, you mean the typing field, not the actual mouse arrow that requires you to click? I would find the latter incredibly annoying. But for the former, I am hardly a programming expert, and haven’t done much web stuff in awhile, but it is possible and trivial to change the Tab Stop order so that that field is first.
It seems that a hacker would just make it hit Tab x times to get to the right spot, no? Unless there’s ways to randomize the order or start location of the selected field.
There is at least one good reason: some sites are designed for keyboard navigation. Focusing on an input field would interfere with that. That’s especially true for login fields that are in the header or sidebar of a content page.
I just checked the login pages of a bunch of popular sites, and almost all of them had focus on the username/login field. This site was the only exception.
It makes no difference whatsoever. Tools that brute-force logins don’t work that way.
One reason for pages not to mess with focus is that can take a non-trivial amount of time for Javascript to start executing. If a user has already typed their username and moved on to the password field, and then the Javascript starts running you don’t want to set focus back to the username field - at the very least you’ll annoy the user by forcing them to go back to the password box (and probably start typing it all over again if they don’t remember exactly where they were when they got interrupted), worse they may end up accidentally typing their password into the username box and it could end up in their browser’s autocomplete database and your server logs.
Possibly this could be worked around by checking if focus has already been set somewhere else and, if so, not changing the focus - but it might also be impossible to tell the difference between the user setting focus somewhere (before scripts run) and the browser defaulting there.
I’m pretty sure you can set the focus without using JavaScript. Only IE9 and lower doesn’t have the “autofocus” attribute. And, even then, you can make the single line of code a separate chunk of script (directly in the HTML) and specify when it takes effect. There’s no reason it would have to wait until the rest of the script(s) start working. And a well-designed script shouldn’t change the user focus (unless it’s having to do some weird, hacky thing.)
That said, I don’t find that it slows me down at all, as I just double click on the field and click my name from the dropdown. I have a hard time thinking that pressing a key and then still selecting the right name would be faster. I almost never actually type in a username/password combo unless it’s a site that involves money. And I like that I’m forced to slow down for, say, making a PayPal purchase.
I did notice that my one financial site that puts the focus where I want it automatically only has one field on the screen at a time. That is, there is the screen where you enter your login ID, and then it goes to another screen where you put in your password. I wondered why they do it that way, maybe it’s so they can direct focus without very much complication.
Thanks for the answers, by the way, it does make things clearer.
Roddy
I think it’s more of a set of security hurdles. If you don’t know a valid user name, you can’t get past that screen. One banking site wanted both a customer ID number and a user name, same setup. It’s just to fend off bot and fraud attempts, I think.
Just for giggles:
In the mainframe world, cursor position was a matter of setting a non-input byte to negative 1.
How difficult is it in the PC world?
IIRC, mainframes work within a UI much like a browser - relatively simple programming because the feature set is so deeply embedded.
With most actual application GUIs, it’s no more complex; set a bit or a field order to position the cursor when a menu opens. However, what’s being talked about here is browser-based access. There is no native HTML/CSS function to position a cursor or focus, at least, not one that’s universally implemented. It’s usually a scripted feature, but is trivial from that perspective and should work on all browsers once implemented.