Search code examples
htmlmacosgoogle-chromepasswordsusability

Google Chrome / macOS: Password field won't accept non-ASCII characters

Update

Apparently this is an unresolved issue with the OS X version of Google Chrome. It was first reported over seven years ago. If you happen to find yourself needing to enter a password containing non-ASCII characters, then here are your options:

  • Type in the password somewhere else and transfer it to the password field via the clipboard.
  • Use the developer tools to change the input type from password to text.
  • Use a different browser

Are there any rules about the characters that can be entered into a password field? I've been experimenting with Chrome on a Mac and it looks like I can only enter "special" characters if they can be produced with a single keypress (not including modifier keys like Alt and Shift).

For example, I can enter a copyright symbol (©) with a single keypress (AltG), but the letter "o" with an umlaut (ö) requires two (AltU followed by O). In the latter case, the umlaut won't appear in the password. In Windows, it seems that these characters are obtained by typing in magic numbers while pressing the Alt key, so there are probably cross-platform differences in this behaviour. There may also be cross-browser differences.

The reason I'm asking is because I want to implement a sign-up form with a password entry field that can be switched from type="password" to type="text". This allows the user to check the contents of the field (assuming it's safe to do so), and allows me to use a random password generator to pre-fill this field with something that the user can then copy into the confirmation field. But by doing so, I'm changing the set of characters that this field accepts. This is obviously undesirable; if I choose Röntgen as a password, for example, I will never be able to log in (unless the log-in form is also switchable).

So what's the best approach here? I don't want to ban special characters altogether, but restricting everyone to printable ASCII looks like the easiest option.

To illustrate the issue, here's a form with two password fields. One field can be switched to an ordinary text input. Click the button to reveal the contents of the two fields.

function reveal() {
  if ($('#p1').attr('type') == 'password') {
    $('#p1').attr('type', 'text');
    $('#r').html('(Hide)');
  }
  else {
    $('#p1').attr('type', 'password');
    $('#r').html('(Reveal)');
  }
}

function show_passwords() {
  $('#out1').html($('#p1').val());
  $('#out2').html($('#p2').val());
}
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
<div>
  <form onsubmit="return false;">
    <p><label>Password:<br><input type="password" id="p1" name="p1" size="20"></label>
    <small><a id="r" href="#" onclick="reveal()">(Reveal)</a></small></p>
    <p><label>Confirm password:<br><input type="password" id="p2" name="p2" size="20"></label></p>
    <p><button onclick="show_passwords(); return false">Show password field contents</button></p>
  </form>
</div>
<table style="min-width:20em; border: 1px solid #bbb">
  <tr><td style="width:8em">Password:</td><td id="out1"></td></tr>
  <tr><td>Password confirm:</td><td id="out2"></td></tr>
</table>

Solution

  • Original author of the report on the chromium bugtrack here. I was told to open the same issue on the webkit's bugtraq (back then Chrome ran on webkit) and a webkit dev told me that Cocoa (OSX UI framework) does not allow non-ASCII characters on password fields (and I've already found that issue, my OSX password is not as challenging as my online services passwords) and that the Webkit tries hard to mimic native behavior. So the problem is not your browser but OSX itself.

    To be fair, when Chrome switched to Blink, there was a new message on the bugtrack:

    This is still an issue. On the original WebKit bug, it was "decided" that allowing dead key input in password controls is not an ideal solution, and WebKit should strive to follow Cocoa's behavior.

    As it stands now, Blink fails in both manners: dead keys do not behave as they do in text fields, and they do not follow NSSecureTextField's behavior either (i.e. behaving a though the key is not a dead key).

    WebKit 601.2.7 in Safari 9.0.1 behaves as expected. Should Blink follow platform behavior as well, or would supporting dead keys in password fields be preferred?

    But time has passed and nothing changed so far...

    I just use Firefox which does not follow Cocoa's limitation and allows any characater on a password field.

    If you don't want to force your users, just skip non ASCII characters from your generated password.