Password generator password not filled into password field
Closed this issue · 15 comments
Expected Behavior
When choosing Show Password Generator from a password field the generator and pressing the Apply Password button the password field that one started all of this from should have the newly generated password in it.
Current Behavior
All of the above happens except the password is not actually populated into the password field it was all started from.
Steps to Reproduce (for bugs)
- Create a yahoo.com account if you don't already have one
- Attempt to change the password
- Observe the above described behaviour
Debug info
No console errors
KeePassXC - 2.7.7 (snapshot from the backport PR)
KeePassXC-Browser - 1.8.12
Operating system: Linux
Browser: Chrome
Any more information needed on this issue? Am I the only one seeing this bug?
Some pages do not accept the fill from scripts, and it needs some special handling. Does normal Auto-Fill still work?
I certainly haven't seen this problem. I have tested the password generator fill on many sites. You'll have to provide the site that this isn't working on to confirm the bug, otherwise it is "just you" at this time.
You'll have to provide the site that this isn't working on
It's in the original comment's Steps to Reproduce:
1. Create a yahoo.com account if you don't already have one
Some pages do not accept the fill from scripts, and it needs some special handling. Does normal Auto-Fill still work?
Not sure what you are referring to here by normal Auto-Fill. Do you mean simply do passwords from KeePassXC fill into the password prompt at yahoo.com when trying to log in? If so, then yes, that works as expected.
This works 100% perfectly for me every time:
2024-02-22_21-57-16.mp4
There doesn't appear to be a problem with KeePassXC or the Browser Extension for this capability. Please conduct more testing to narrow down the cause and also report if this only happens on yahoo.com.
Please let's reopen this. I am able to reproduce the success you show in your video. But that's not where I am having the problem. The form that the password generator refuses to fill in is a forced password change at login form. I seem to get forced to change my Yahoo password on the order of once per week (or more) and it's that forced password form that fails to get filled in with the generated password from KeePassXC.
I will attach a video the next time I am forced to change my password.
What other steps can I take to provide additional information about this issue?
This would need a step-by-step debugging to see at which step the input gets cleared. It might be possible that some page script interferes with that specific input.
This is not our bug. We can't possibly overcome all the dumb things websites do. Just copy and paste the password from the generator.
Except that I would never know that I actually need to do that until it fails and then I have to go back and regenerate a new password and then copy and paste that back.
This makes this a very user-unfriendly solution. How am I supposed to give this to my wife or mother with all of these "well, if this happens then do this instead" caveats when the built-in Google password generator works just fine for all of these cases of "dumb things websites do"?
Please excuse my frustration here, but KeePassXC[-Browser] takes something that is so simple for users to use (Google password manager) and turns it into a rocket science project where there is forty-eleven things that users need to know because of "dumb websites".
I guess this whole project/solution is really just for nerds and the general public cannot be expected to be able to cope with it. Sadly.
I have sometimes seen this behavior with some pages and I have been unable to fix it. There might be some JavaScript that prevents filling if it's not "done by human", and we are trying our best to add events to the input that would impersonate a real filling event. Sometimes this fails, and we have no access to the same inside-browser API's that Google's password manager has (which probably does input field detection, filling etc. so much better), and we don't have the capacity of people to do fixes right away.
Your choices are (only a single one): wait until I (or someone else) has time to reproduce this and try to fix it. The issue itself is not new, and I can add this to the Non-working sites list to be checked later.
I'd prefer not to be targeted by anyone frustrations, thanks.
@varjolintu Your response seems measured and fair. Thanks for taking the action of adding it to a TODO list to be resolved in the future.
It's really a shame that being in the browser (such as Google's password manager) works so flawlessly but external password managers have to suffer so much.
On the other hand, some browsers, such as Chromium (and all browsers based on Chromium such as Chrome, Vivaldi, etc.) are open source. Would the time that would go into fixing all of the #1358 sites be better spent contributing a proper and fully functional API for password management into Chromium so that this problem is solved once and for all?
It's really a shame that being in the browser (such as Google's password manager) works so flawlessly but external password managers have to suffer so much.
Well. A few coders with a normal day job that takes majority of the time anyway vs. multi-million corporation that owns the browser..
On the other hand, some browsers, such as Chromium (and all browsers based on Chromium such as Chrome, Vivaldi, etc.) are open source. Would the time that would go into fixing all of the #1358 sites be better spent contributing a proper and fully functional API for password management into Chromium so that this problem is solved once and for all?
In my opinion browsers should open their input field detection (and Passkey) API's for 3rd party developers to use. It would be much easier to handle input fields and filling if all of the developers had the same access. So far there has been no interest in these kind of things.
Well. A few coders with a normal day job that takes majority of the time anyway vs. multi-million corporation that owns the browser..
Indeed. Understood.
In my opinion browsers should open their input field detection (and Passkey) API's for 3rd party developers to use.
Ideally, yes.
It would be much easier to handle input fields and filling if all of the developers had the same access. So far there has been no interest in these kind of things.
But some browsers, indeed, some of the most popular browsers are based on the open-source Chromium project. Doesn't this make it possible for somebody to expose the input field and filling handling to an API to it and contribute that back upstream to the Chromium project so that 3rd party developers all have such an API to use? I.e. Rather than spending that time playing whack-a-mole with trying to fix every "dumb website" problem that will never cease to end, develop that API.
I guess this whole project/solution is really just for nerds and the general public cannot be expected to be able to cope with it. Sadly.
That set of folks (nerds) is certainly a primary customer for us. Security vs convienence is unfortunately a reality. We are also dealing with the reality of not having full control of the end to end experience. The browser doesn't expose its full power/control to extensions (for good reasons).