The login form used to have an intuitive behaviour up to a few days ago: pressing the tab key would switch from the email field to the password field, just like pretty much any such login form under the sun. For some reason it was changed recently and pressing the tab key from the email field switches to "Forgot password?" which isn't the expected behaviour in a login form. Could this change be rolled back to an intuitive behaviour?

Also could we have the email field automatically selected when the login page is opened? It's also what I would consider the most intuitive behaviour when a page is dedicated to login.

EDIT: as mentioned in comments and in another question, it also breaks password managers that rely on the fact that typing the login, tab, then the password should just work.


4 Answers 4


A fix for this has merged into master and will be built soon, likely sometime tomorrow.

I first looked into solving this by implementing tabindex on each of the inputs, but the latest thinking behind implementing tabindex is... "don't". Both MDN and Google use verbiage that describes it as an anti-pattern, since it locks keyboards into tabbing between only those elements that include it. And like z-index, you can end up in an arms race between elements.

Instead, we should rely on the order of the DOM. Unfortunately, we really love the visual layout of putting the forgot password link where it is, especially since it's close to the task at hand. We've actually flipped the source order of that password block, and then flipped the display back using flex box's column reverse.

It's an interesting approach, but solves not needing to rely on tabindex, and it also keeps us from throwing a tabindex="-1" on that link, disabling tabbing to it—something we really don't want to do.

We can consider moving the forgot password link entirely in the future, but this fixes the workflow for now and maintains that nice layout.

  • 1
    Thanks for fixing this! I was thrilled to find I could go back to using my password manager today without re-configuring it for every SE site. Also thanks for the research and idea on how to have your cake and eat it too.
    – Caleb
    Commented Mar 25, 2019 at 6:11

This is an important bug that should get fixed. My login manager broke because the standard <USERNAME><TAB><PASSWORD><ENTER> sequence no longer works. Either the link should be moved after the password input field or the HTML tab order property should be set.

Of course every user could just retrain their fingers and I could add an exception to my password manager, but this is something developers can fix to make everybody else's lives that less surprising.


Now the tab order is broken!

The displayed order is

  1. 'Email' input
  2. 'Forgot password?' link
  3. 'Password' input
  4. 'Log in' button

The current tab order is

  1. 'Email' input
  2. 'Password' input
  3. 'Forgot password?' link
  4. 'Log in' button

A typical expected tab order by keyboard users is

  1. 'Email' input
  2. 'Password' input
  3. 'Log in' button
  • Most of the time, intuitively, people press Tab after entering their email/username on a login field to enter their password. Also, as per the comments on this question, there are password manager extensions that depend on pages having Password come after a single Tab push. I don't think this is broken. Commented Apr 3, 2020 at 20:11
  • Thank you for the explanation. I still think think, in the tab order, forgot password should come after the Log In Button. Then the password managers will still work. And that is the usual order. Currently it is neither aligned to the visual order, nor the usual order. One could think my suggested order as left to right
    – Sebastian
    Commented Apr 3, 2020 at 20:44

This isn't really a bug, it's part of a design change.

This is how the login form used to look like: (wayback machine screenshot)

As you can see, the "forgot password" link is below the password field, and very small. I'm pretty sure many people complained they can't find it, so SE decided to change the design and put it in a much more visible place, with clear text:

Since none of the elements have a tabindex, the browser decided it itself, based on the actual location of the elements, hence the bad order we see in use.

  • 8
    Then simply adding tabindex values should fix this problem, right?
    – quazgar
    Commented Mar 18, 2019 at 9:15
  • @quazgar should is the key... and since things are always more complicated than how they look like, doing that has big chance to cause other, much bigger, bugs. (e.g. people won't be able to login at all) Bottom line: even such a "small" change will require long hours, maybe days, of developer time, to properly test the changes and try to fix the bugs they cause before it's launched. Commented Mar 18, 2019 at 9:18
  • 3
    I don't think there is a need to provide a rationale for this regression (mess) retroactively.
    – moooeeeep
    Commented Mar 19, 2019 at 22:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .