[Password Managers] Some password manager icons do not show up on input fields

[rianadon]

Checklist

• [X] I have updated to the latest available Home Assistant version.
• [X] I have cleared the cache of my browser.
• [X] I have tried a different browser to see if it is related to my browser.

Describe the issue you are experiencing

This issue is for discussing remaining password manager bugs that have arisen in spite of now having a polyfill in place to support password managers.

I'm continuing discussion from #3133, now that we have an issue specific to password manager quirks.

LastPass

I can reproduce @Nowaker's issue with LastPass. Their browser extension made the interesting design choice of adding their clickable icon to the background of the input element. It looks like there are also mouse move & click listeners somewhere that swap the image when you hover over the LastPass icon and know when you click on it.

LastPass successfully finds our polyfilled elements and adjust their background color (although the mouse move detection does not appear to work), but since they are hidden the LastPass icon will never be visible.

Safari

@soundstorm: Safari adds its password fill menu directly to the input element. This menu looks like it is the only way to save a password from the Home Assistant page. However, I see no other way to making this menu visible other than displaying the polyfill element.

The silver lining is that once a password is created within Safari, the autofocus lets you fill it in right away.

Note: it is possible to enter the credentials via Safari preferences, but this is a more roundabout way than using the menu.

Other password managers

@creack I tried the Bitwarden extension in Firefox and filling in the password works from the icon next to the address bar. It doesn't look like their extension adds icons like LastPass does, so I'm curious what is not working for you.

The only password manager for which the icon showing up does work is KeePassXC (last tested at the time I wrote the polyfill)

Solutions

I don't think there is any change we can make that will allow Safari and LastPass to show their password autocomplete icons. If anyone has a burning need to write a PR to fix this issue, I suggest adding a "my password manager doesn't work" button that un-hides the polyfilled elements.

[creack]

I didn't try the latest version, it may be already fixed. Bitwarden extension in Chrome simply wouldn't fill the fields on both the web ui and the mobile app.

[deviantintegral]

Something is up with filling on iOS too. Earlier today, I couldn't get autofill working in Safari at all. I'm using 1Password, but normally use the system-level filling so it should be the same behaviour for any password manager. Then, it worked, and I added the app to my home screen, but when logging in again (as session data is separated) there's no offer to fill at all.

As well, it's detecting the username field as normal text, and is auto-capitalizing the first letter when it shouldn't.

[leonelsr]

Google Chrome's own password manager (without extensions) also doesn't work. The same happens on Chromium-based Microsoft Edge, vanilla password manager doesn't recognize the fields.

[Nowaker]

SOLUTION: Stop using fancy JavaScript shadow DOM / single page application / whatever comes after Web 2.0 frameworks to build a freaking login page. A simple HTML from the 90s will do better!

[leonelsr]

SOLUTION: Stop using fancy JavaScript shadow DOM / single page application / whatever comes after Web 2.0 frameworks to build a freaking login page. A simple HTML from the 90s will do better!

Ok, I understand that putting such a request in h1 (or markdown's #) letters doesn't seem to be a very polite approach 😅 Also nobody will simply stop using frameworks and stuff. But, ffs, he does have a point!

At least, let's please care having proper and working polyfills (also called "shims") always in place, in order to cover most current use cases and scenarios.

I'm not even talking about backwards compatibility (as in IE11 down to IE6... whatsoever), but password managers are increasingly becoming popular these days, as digital security is such a big concern for everyone.

They (even "vanilla" ones) make it easier for users to generate, set and use passwords that are unique for each service, app or website. But usually those are very hard to remember OR type, and ain't nobody likes having to copy and paste stuff anywhere!!!

All that to say this should be treated as a serious, big and important UX bug, because it is!!! 😬

Thanks! Best Regards.

[Nowaker]

Ok, I understand that putting such a request in h1 (or markdown's #) letters doesn't seem to be a very polite approach

Before I answer that, let's look at the background first:

Oct 23, 2019 - 8 upvotes - @Nowaker - I guess the login page should be a regular HTML login page if SPA makes the basics overly complicated.

Sep 24, 2020 - 29 upvotes - @Nowaker - Can we simply stop using the latest tech that is password filler and usability unfriendly and go back to normal HTML? We don't need the 2020 tech on the login page. 1995 tech sans the gradients and shadows will do...

Apr 18, 2021 - 19 upvotes - @Nowaker - The login page should be a regular HTML login page if SPA makes the basics overly complicated.

Apr 18, 2021 - **30 upvotes ** - @johanson - The founder seems to suggest it wont' be fixed - #1622. I agree with @Nowaker, common sense would be the login page to work with password managers, not aiming for to be 100% x framework.

It's been almost three years since #3133 was reported, and two years since not using SPA for the login page was suggested, and still counting.

Secondly, password manager support ticket (#3133) is the TOP1 most upvoted ticket of all times for HA frontend - 172 upvotes, ticket is closed, and the problems are still arising. The second most upvoted ticket is #4614 with only 37 upvotes.

So, commenting on what you said - of course, it wasn't polite, but closing and locking the TOP1 most upvoted ticket wasn't polite either. The use of h1 is just a tribute to these 172 upvotes, since the maintainers do not consider "use 90s tech on login page for simplicity" a valid request, as evidenced in #1622.

[rianadon]

I don't like moderating here but I would like to clear some things up before the discussion becomes off-topic.

Also nobody will simply stop using frameworks and stuff. But, ffs, he does have a point!

This is why the login page is not a simple page. Using the same framework & components as the rest of HA makes the page easier to maintain. And the login page isn't always just a username & password; there are a few different configurations.

At least, let's please care having proper and working polyfills (also called "shims") always in place, in order to cover most current use cases and scenarios.

There is a polyfill that, until @leonelsr's comment, I believed covered the Google Chrome builtin manager and a few of the most popular password managers. This issue is for tracking the remaining password managers with which the polyfill does not work. I've edited the first comment in this chain to make this clearer, but I worry not everyone is reading it.

I hope we can keep discussion to the polyfill and how to improve it, since talking about re-writing the frontend with a separate set of components gets us nowhere.

[github-actions[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[Nowaker]

bad bot

[leonelsr]

Chromium (Chrome and Edge, at least) built-in password manager still doesn't work.

[Nowaker]

And the login page isn't always just a username & password; there are a few different configurations.

With usage rate of what, 5% at most? If any of these are enabled in that particular HA setup, sure, whatever, render the fancy dandy Web 3.0 rainbow.

Otherwise, I'll repeat my words again: Stop using fancy JavaScript shadow DOM / single page application / whatever comes after Web 2.0 frameworks to build a freaking login page. A simple HTML from the 90s will do better!

[iBobik]

Here Safari iCloud Keychain and LasPass not offering password save nor filling manually saved password.

[github-actions[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[Nowaker]

bad bot

[Nowaker]

172 upvotes on the previous ticket: https://github.com/home-assistant/frontend/issues/3133 - we won't go away.

[kjake]

Ugh, this is annoying. This doesn't work in Chrome, or the iOS companion app (Safari).

[blakek]

Repeating what I said in #11001…

The input elements should use the HTML autocomplete attribute. I don't know Polymer very well, but I believe if the autocomplete attribute were accepted here and the autocomplete type provided by the forms (don't know where to find that) that'd fix this issue.

[steverep]

Adding autocomplete is my intended fix from an accessibility standpoint, which I suspect would fix the Safari/iOS issue.

As far as getting icons to show up and work for third-party browser extensions, I'd be inclined to throw the issue back to the extension if autocomplete doesn't work.

[RosemaryOrchard]

Adding autocomplete is my intended fix from an accessibility standpoint, which I suspect would fix the Safari/iOS issue.

Just to confirm, this is correct. The Apple Developer Documentation shows it. Ideally, it would be added to the 2FA token and password change fields too.

[steverep]

Just to confirm, this is correct. The Apple Developer Documentation shows it. Ideally, it would be added to the 2FA token and password change fields too.

Yes, I can add it there and any other relevant places, just haven't gotten to it yet.

[steverep]

The autocomplete attribute has now been added in the following locations, and is in the current beta release for 2022.11. At a minimum, I expect autofill on Safari/iOS to now work for all of these because it does not require the polyfill for shadow DOM support.

• Login including MFA code
• Password changes and MFA setup
• HA cloud registration and login
• Creating new user during onboarding
• Many integrations that require external usernames/passwords during setup

However, please note that only the main login form currently uses the polyfill for shadow DOM, so browsers/extensions that still don't support shadow DOM won't see any effect in the other areas. I know there are active bug reports on this for Chrome, Firefox, and popular extensions like BitWarden.

Please test with your particular password manager and report any unexpected results here.

[RosemaryOrchard]

Auto fill on iOS (specifically the iPad app) was broken today on 2022.11.0b6 as the 2FA code auto filled into the password field.

[Nowaker]

However, please note that only the main login form currently uses the polyfill for shadow DOM, so browsers/extensions that still don't support shadow DOM won't see any effect in the other areas. I know there are active bug reports on this for Chrome, Firefox, and popular extensions like BitWarden.

We have an active bug report in Home Assistant:

Please stop using fancy JavaScript shadow DOM / single page application / whatever comes after Web 2.0 frameworks to build a freaking login page? A simple HTML from the 90s will do better!

[steverep]

@RosemaryOrchard can you inspect the DOM and verify the value of the autocomplete attribute is "current-password"? I don't see how it could be anything else but I'll check to make sure I didn't mess up. You are using a standard Home Assistant login correct?

If you can verify the value is correct, the culprit is probably whatever password manager you are using.

[RosemaryOrchard]

Sadly inspecting the DOM of the iOS app on an iPad is not something that is easy/possible to accomplish. I am using 1Password, but through the native iOS autofill. That said, it pops up Safari window which does not run any extensions or modifications, so it can't be one of those interfering with it.

[steverep]

You can use this extension to inspect on iOS:

https://apps.apple.com/us/app/web-inspector/id1584825745

[RosemaryOrchard]

You cannot use the inspection as it's an in app Safari, that means it uses WKWebView. For clarity: You can't even use the native Safari keyboard shortcuts for autofill, extensions are not available (as stated above), and it doesn't even share cookies with Safari.

If I inspect in Safari itself, I can see the HTML which seems fine, but autofill does not work. ha_login.txt.

[steverep]

You cannot use the inspection as it's an in app Safari, that means it uses WKWebView.

Right I was asking to inspect in Safari. I would not expect different autofill behavior in the web view.

Auto fill on iOS (specifically the iPad app) was broken today on 2022.11.0b6 as the 2FA code auto filled into the password field.

Are you saying that the username filled correctly? I'm confused now because the screenshot says nothing was auto-filled. Is that an error from 1Password?

[steverep]

@RosemaryOrchard I did make one more change to make sure that the fields have a name attribute in addition to autocomplete. This is in 2022.11.0. Please let me know if that makes a difference.

FWIW, I tested all the locations I listed with BitWarden on iOS and autofills performed as expected.

If anyone uses iCloud Keychain, some feedback on how that behaves in 2022.11.0 would be appreciated (or any other specific password manager for that matter).

[steverep]

FYI - the Chromium issue for autofilling inside shadow DOM was just marked fixed