Keepassxc-browser: password generator does not save generated passwords

[metaxis]

Generated passwords are forgotten like tears in the rain unless you explicitly go save them somehow. This is super easy to forget. Keeping track of all generated and used passwords seems like a basic feature for the built-in generator, so this lack of a safety net is surprising.

Expected Behavior

If I generate a password and use it, I expect it to be saved.

Current Behavior

If I generate a password and use it, keepassxc-browser does not keep it.

Possible Solution

Save the password immediately with nominally useful default values if the fill password or copy button is clicked, so the person has basically no chance to accidentally forget to save the password.
The downside of potential "clutter" of unused passwords can be mitigated by tagging auto-generated to not autofill, but are still searchable, very much like some other Kee plugins.

Steps to Reproduce (for bugs)

1. use the password generator
2. look for the password you generated later
3. it won't be anywhere

Debug info

KeePassXC -2.6.1
KeePassXC-Browser - 1.7.1
Operating system: Win
Browser: Firefox

[varjolintu]

Just to be clear: the Password Generator is just a password generator, and it works just like in KeePassXC. It doesn't save any password by default, it just generates them. Saving the credentials happen on the form submit, or manually using context menu and choosing _Save Credentials_.

Adding a history for the generated passwords could be a nice new feature.

[metaxis]

Got it, agreed. generated password backups would be great.

However this report/request might actually be inspired by a bug of sorts.

More than once I've run into a situation where the saved creds are mangled after the form submit, so while there is an entry saved in keepassxc it doesn't work and the password is irretrievable (to my knowledge). This happened again last night which is what triggered me sending this report.

I have the broken entry and the passwd field is filled with 696 characters, starting with "AAEAA..." (not password related) looks base64 encoded, as it ends with "==" padding. Decoded to binary and no I didn't try to fingerprint it at that point. Username and URL are correct.

[varjolintu]

I've also seen some sites that actually alter the input field value before/during form submit, and the extension will use that altered data instead.
The situation you encountered to gives me an idea that it could be useful to store the filled password and compare it to the one at form submit. If it differs, we could show an error, and maybe print some details to the console.