9

I've noticed an issue with password inputs and IOS devices. When you focus on a password input the keyboard should display but instead I get an empty white box.

This is happening on the most basic password input:

<input type="password" name="password">

And I've tried a few variations:

<input type="password" name="password" autocomplete="new-password">

Currently I have a 'work-around' which starts the input as type="text" then once the user has keyed a character change the input type to password (which keeps field hidden/secured but allows keyboard to display). The issue with this is that is won't autocomplete existing passwords (e.g. on login screen select email + autocomplete password).

Here is the issue on Google's login screen replicated using BrowserStack (we've also replicated this issue on real device) iPhone 11 IOS 13

iPhone 11 IOS 13 Password Missing Keyboard Bug

Update: This is effecting IOS 13 + 14, but not earlier versions.

NickMcB
  • 897
  • 1
  • 8
  • 17
  • Hey, I'm not sure about this, but we use autocomplete="current-password". Try that instead of new-password to see if it changes your results. Maybe see if autocomplete="off" changes something. – Michael K. Feb 15 '21 at 09:40
  • Yeah theres a few places we have this type of password field, and we have both current-password and 'new-password', haven't tried 'off' but would be a shame to stop autocomplete. Seems like a iOS issue rather than anything else. – NickMcB Feb 16 '21 at 10:45
  • Seeing the same issue as well. Did you manage to get a fix? I tried setting the field to type to "text" initially, then on first focus or key event, change to "password". Seems to work, but i haven't implemented it globally yet across my application in hopes for a better fix. – raj Feb 28 '21 at 17:37
  • @raj no im still using the work around I mentioned (same as what you're doing). But I've noticed this causes another issue, because without focus the input type is 'text' is doesn't allow for password auto-fill. I'm not sure what to do really, I want auto-fill to work, and I also want people who don't have auto-fill to be able to complete the input – NickMcB Mar 15 '21 at 15:43
  • I have similar problem, but with React Native app and we were not able to reproduce it on real device, only on BrowserStack (iOS 13+). What real device have you used? – pr0gramist Mar 23 '21 at 09:33
  • @pr0gramist, interesting, the QA team told me they tested on real device (I don't have any iPhone to confirm myself), I believe it was iPhone 11 but I'll have them double check this again. I'm not familiar with React Native, but wondering if it's doing some magic behind the scenes (converting to native field which doesn't have the issue) – NickMcB Mar 26 '21 at 22:17
  • @NickMcB All major browsers ignore autocomplete="off" in login forms. https://stackoverflow.com/questions/3868299/is-autocomplete-off-compatible-with-all-modern-browsers/21348793#21348793 – Mark Smith Sep 15 '22 at 17:59

2 Answers2

7

From what I can gather, BrowserStack uses Screen Mirroring to display the device. Apple introduced a security update as of iOS 13 where passwords type inputs hide the keyboard on the screen you're casting/mirroring to. You can replicate this by testing it on an Apple TV, or by sharing your screen during a call. Therefore, it's not really a bug, but a limitation on testing on a platform instead of physical device.

Sargis
  • 1,196
  • 1
  • 18
  • 31
Mathieu Godin
  • 71
  • 2
  • 7
  • 1
    I'd love to find an official reference to this change but I can't see it in any release notes. According to SauceLabs (similar to BrowserStack) it was introduced in iOS 13.2: https://support.saucelabs.com/hc/en-us/articles/360047722533-Password-input-or-keyboard-aren-t-showing-up-on-session – Tom Robinson Nov 12 '21 at 16:54
  • 1
    Just to follow up on this @TomRobinson , browserstack released this (very vague) FAQ [entry](https://www.browserstack.com/question/717) – Frank Navarrete Jan 03 '22 at 23:24
  • As mentioned above - the issue was seen on an actual device – Jose the hose Apr 11 '23 at 20:48
3

Certainly this could be an iOS update bug issue, I can suggest a different way to simulate the password input...

First add this to your custom css file or anywhere you make your css classes:

Basically you are creating a class to mask the input to hide the password

/* Mask the input as password */
.password-mask {
    -webkit-text-security: disc;
    -moz-webkit-text-security: disc;
    -moz-text-security: disc;
}

Then you can use it right in your input like this:

<input class="password-mask" required type="text" autocomplete="current-password">

For the autocomplete attribute, you need to use: current-password in order to make it behave as the password input.

NaturalDevCR
  • 803
  • 1
  • 11
  • 34
  • Thanks @Larav I think this could work, I had read about this but initially decided against it due to possible (I'm not sure if there is one) security issue - also wasn't sure if autocomplete would work but just done a basic test and looks like it does. – NickMcB Mar 26 '21 at 22:12
  • @NickMcB yes it does, so far I know there is no security issue, since it’s basically doing the same as does, masking the input and nothing else, actually if you test it, you’ll see that it’s not possible to copy the actual content of the masked input. From what I see is a valid replacement. – NaturalDevCR Mar 26 '21 at 22:35
  • @LavaDev, for security I was thinking the value of the input would be visible when inspecting HTML (and there for it would be accessible to any malicious JS, where as with type="password" it would not be. I've checked this also, and looks like I was wrong, I can see with simple event listener its possible to get [password] event value: https://codepen.io/NickMcBurney/pen/NWdrjWm – NickMcB Mar 28 '21 at 09:48
  • @NickMcB it’s absolutely possible to see the password when using type="password” and simply inspecting the element in your browser and changing the input type to text, this behavior has been there always, you can do this on any website, and this is why storing passwords in the browser Is not totally safe, but anyway, the security should be on using https on your site, and handling CSRF security as it should be, at the end if the user is infected by a malware there’s nothing you could do to protect their data, that’s why 2FA is widely used these days, since adds an extra layer of security. – NaturalDevCR Mar 28 '21 at 13:10