Password save banner disappears too quickly or does not appear at all on some sites

[dafadllyn]

The banner that lets one save or update a password disappears too quickly on some sites (e.g. amazon.com, outlook.com) and does not appear at all on some other sites (e.g. gmail.com, microsoft365.com, icloud.com).

Setting 'Number of allowed redirects' to infinite does not help.

Debug info

KeePassXC - 2.7.4
KeePassXC-Browser - 1.8.4
Operating system: Windows 11 (10.0.22621 Build 22621)
Browser: Firefox 109.0

[droidmonkey]

Go to the extension settings and increase the redirect count. It's near the bottom.

[varjolintu]

@droidmonkey The redirects were already set to infinite as the issue text says. So let's reopen this.

[droidmonkey]

Whoops, missed that bit

[YellowOnion]

Definitely an issue with the page refreshing or redrawing, the embedded password generator is a liability at this point.

Hold up why is number of redirects set to 1 as a default? Dumb defaults like this piss me off, specially when other UX features encourage you to generate passwords in the page and then you just lose the password after you sign up to the service, I don't even understand the point of this feature, why would you want to artificially lower the redirect limit.

[varjolintu]

@YellowOnion The whole setting exists because some users wish that the banner is always visible until dismissed, and some want it displayed only once after login and not with further redirects. Just giving a possibility to configure it as you like. The latest version 1.8.5 increased the default value to 3.

@dafadllyn If the banner doesn't display at all, it's probably because the form submit hasn't been detected properly.

[Artiom-M]

The same problem with google accounts on Vivaldi browser. I've tried to mark fields manually: doesn't help.

[spacegaucho]

If functionality is all you guys care about then there's a work-around that practically makes the banner unnecessary.

• By functionality I mean, the ability to save the password (before the page refreshes) without loosing it after a first login/set password prompt.
• Workaround: type in your user and password, then right click on the user/password textfield and select the KeePassXC-Browser, and then hit Save Credentials.

[bburdette]

trying to log in to yahoo email. set redirects to infinite, the value there appeared to have defaulted to 1. didn't help; the dialog gets nuked after page refresh.

would be nice if the last entered creds were available to be saved after this happens, like through a right click menu item on an extension icon.

[droidmonkey]

I wonder if a lot of these issues are related to the generic ID of the banner @varjolintu

[varjolintu]

I wonder if a lot of these issues are related to the generic ID of the banner @varjolintu

Might be. Gotta fix that asap.

[Rincemac]

Since it also just happened (again) to me, too, I have to add my 2 cents here.

When using the "classic" KeePass and its browser extension I never faced these user unfriendly UX issues. You cannot expected a user to "anticipate" the banner getting nuked when creating a new login. Especially when, as recommended, using the random pw generator to apply a random PW.

This frequently happens on KeePassXC browser plugin on various sites. To expect someone to set "redirects", when the standard setting is set unecessarily set to "1" even it is tantamount to "how to have a bad user experience". It's counterintuitive and might compel to not use the random generator. When using it, user doesn't know (and shouldn't) the password - neither will they remember a string of random chars - so the pw is lost from the get-go.

I am and advanced / expert level user and it still gets me all the time, especially since the banner is nuked either way on some sites at random.

I just had to "recover PW" on a newly created account for this very reason (Autodesk site) - please fix it, it's very annoying and an immediate turn-off to use XC random PW generator as one should do in good practice.

Some points for possible better UX:

KeePass classic (2.x) has its extension icon "pulsating" immediately after new credentials are applied and would be available to save as a new entry. This compels a user to click it and then have them (immediately) saved to a new entry. I am amazed XC doesn't copy this behaviour, since it works pretty well.

Possible Solutions in XC browser extension UX:

• once a user creates a new account, immediately offer to save a new credential entry. Why not make the banner permanent (if possible, or at least visible as long as possible) until dismissed by user - To alleviate user complaints, why not reverse mechanic and have an option in Settings to "dismiss new entry banner after X seconds" (?)
• it might also be a good addition to have an button option in the PW generator itself. ie. "Save credentials" to immediately do it when applying this random password to a new account (-> this would also be usable when updating to a new random pw with an existing account)?

[varjolintu]

KeePass classic (2.x) has its extension icon "pulsating" immediately after new credentials are applied and would be available to save as a new entry. This compels a user to click it and then have them (immediately) saved to a new entry. I am amazed XC doesn't copy this behaviour, since it works pretty well.

This was the original implementation. This caused users to miss the whole new credentials prompt because it was hidden under the popup. And it also forgot the settings, or user wanted to use the normal popup instead of storing new credentials.

* once a user creates a _new account_, **immediately offer to save a new credential entry**. Why not make the banner permanent (if possible, or at least visible as long as possible) **until dismissed by user** - To alleviate user complaints, why not reverse mechanic and have an option in Settings to "dismiss new entry banner after X seconds" (?)

The banner should be displayed until it's dismissed if the option is set to infinite. We are doing improvements to this feature, sooner or later.

[Rincemac]

Thanks for the notes, appreciate the reply - despite having infite set sometimes the banner gets mysteriously killed - this especially happens when some sites reload what I suppose to a different subdomain or similar. Ie when the "create account" form seems to be on a totally different subnet or maybe even domain.

The right click method is usually also not valid here since you're prompted on some sites to have password created/entered after confirming mail (or these are handled in two separate steps, ie first email field -> confirm -> create password -> confirm.

I find that the banner getting lost is happening especially with these two-step sites. Autodesk (https://tinkercad.com) just was a culprit here if you want some sites for testing maybe.

Hope you'll find what's causing this, and good hunting 🐞

[varjolintu]

Thanks for reporting a site where this can be easily reproduced. That already helps.

[Jarartur]

Hi,
recently it happened to me too. The banner disappeared after generating a password on some internal university webpage (I have set the redirection amount to infinite). I do not have any idea about web development so take it with a grain of salt, but I have yet to use a password manager extension that does not have this missing popup issue (e.g. bitwarden suffers the same).

The way 1Password overcomes it is that when you select "generate password" on a form it automatically prompts you to save that login info before submitting on the page itself.

I learned from this thread that it is already kind of possible by right-clicking the password field and selecting this from the context menu. Maybe it would be a good idea to make this more discoverable by displaying the banner to save login info after the generated password gets inserted, i.e., before the user clicks submit on a web page?

[varjolintu]

@Jarartur I think the correct way to fix this approach is to do this feature: #2424. If succesfull, the default prompt for new credentials would always redirect to our extension. Still haven't tried this in action, so I cannot promise anything.

The submit detection itself is very tricky because websites are not using a standard way for it.

[Jarartur]

@varjolintu I don't think what I described in 1Password is related to this Firefox setting. It works regardless of the browser because it does not detect when a user submits the form. It only detects when a user generates a password.

What I was proposing was not to even detect the submission, but to treat the password generation itself as a prompt to save the login info.

The typical workflow would be as follows:

1. I open a webpage with a form to create an account
2. I put my email there and click the key icon on the password field to generate a password
3. KeePassXC window oppens, I click "Apply".
4. The password gets filled in on the website and a banner pops up asking me if I want to save this login info
5. First I click save on the banner and only then I click submit on the webpage

This way I know for sure that the generated password is already securely saved when I submit the form. Even if my browser crashes right after I clicked submit, the login info is already saved.

[varjolintu]

@Jarartur I will consider that approach as well. Thanks.

[Jarartur]

In case this is of any help, this is how it looks in 1Password. The popup stays after submitting the form until the user clicks on either save or x.

I just saw how many issue tickets there are for non-working sites, this kind of eliminates this problem.

Nagrywanie.ekranu.2025-01-23.155624.mp4

[varjolintu]

@Jarartur This would still leave those situations unsolved where user has entered the password manually, or logged in with credentials that are not found in a database. But at least this would be one step to the right direction.

[Rincemac]

@varjolintu - since I've been pinged (subscribed to thread) some UX suggestions:

Sites/Instances of banner getting "lost" or not even shown (due to user behaviour):

• User generates a Password via "Random function" (dice icon or right click) -> automatically prompt to "Save info temporary" (commits to temp save/account w/o user)
• Tricky to catch: user enters a Password manually (which is not recommended anyway...) -> try to match/catch "Password:" fields (?) and then use same prompt "want to temp save?" (commits to temp save in "Browser saved PW area" (maybe utilize a checkmark "temp password/account info" to match later (-> purge function for non-completed entries where user name is still missing)

Possible UI/UX catch:

• The popup/banner for these cases can be something like "did you just create a new password somewhere?" to make it clear that the tool is not sure but wants to give the option to save...

That's the "try to catch" approach on weird instances with rerouts/2-step verifications
(-> I noticed a veritable uptick in these registrations being used... ie it asks for mail first, then sends you a "complete registration link" to mail and then lets you create PW only after that...)

Not sure if this helps, but that would be a very clear "user flow" imho for "rare instances" but obviously can also lead to some additional false "nags" (I'd rather have those personally than get a random password lost).

Alternative 2:
Catching URLs in a crowdsourced manner -> help everyone by users filling a "offenders" database somewhere if they want to. If "try catch" is a positive catch you could prompt to "Help our community & commit this site to our database for better future recognition" (=commit URL to anonymous database that just records domains/redirects?)

[benwaffle]

@varjolintu even in cases when the user enters the password manually, you can offer to save before submission. Here's how 1password does it:

1p.mov