"Fill Password Only" not working

[icamps]

trafficstars

Overview

There are some authentication pages in my university that blocked the possibility to add both login/pass in the authentication pages. After that blocking, I add the login info first, and then, after going to Fill Password Only, I could add the corresponding password.

Since few days ago, after doing the process describer above, I am getting the error message:

Filling password to a plain text field is prevented.

Steps to Reproduce

1. Open a page where login/password input is blocked.
2. Add only the login info.
3. Go to Fill Password Only and try to add the password only.

Expected Behavior

I expected that the password is injected in the text field as previously.

Actual Behavior

The password in not injected and an error message appear:

Filling password to a plain text field is prevented.

Context

I am using the Brave v1.63.165 (Feb 28, 2024)

KeePassXC - Version 2.7.6 Revision: dd21def

Operating System: Linux Desktop Env: Gnome Windowing System: Wayland

[varjolintu]

Choose the input field manually using Custom Login Fields to override this.

[hazelnot]

Choose the input field manually using Custom Login Fields to override this.

This doesn't work either. I set and saved the custom password field, but it's still not detected nor does it allow me to enter password only. This is happening on Firefox 123 on Arch Linux.

[ccady]

I have the same issue here. Being more careful is laudable, but I use KeepassXC to fill in passwords into plain text fields, so I need this to at least be allowed, either globally, or on a per-password basis.

[Flamefire]

Same here (Firefox on Windows)

The particular input form has an option to show/hide the password which changes the input-type attribute. I guess this confuses the extension and there is no way to make it still put in the password even when explicitely requested to do so. An option to allow this is hence required.

[xxyxxyxyx1]

I also have the same problem. I chose the input field manually using custom login fields, but I still get the same "Filling password to plain text field is prevented" error. I'm using Firefox 126 on macOS.

@varjolintu this issue should be reopened, the posted solution does not resolve the problem for multiple people.

[varjolintu]

Reopened. Can you give my sites where this happens? I have tested this locally and with multiple pages, and I have no issues if I select the password field using Custom Login Fields.

[xxyxxyxyx1]

Thank you for reopening.

Unfortunately I cannot provide a link to a site on the public internet where I have this problem. I experience it in two cases:

• a site within my employer's private intranet, which might be designed weirdly
• controlling networked computers using cockpit, which provides a terminal in the web browser. I often need to enter a password for sudo commands, and it would be much better to do this with a keyboard shortcut and the browser plugin, instead of copy/pasting from the main keepassxc application.

[varjolintu]

I think one solution would be to add a separate option for this in the extension settings. Users could disable this check if they want to. There might be cases where entering the password to a plain-text field is needed but Custom Login Fields might not work in that scenario.

[xxyxxyxyx1]

That sounds good to me. It could be added as a field in the "Site preferences" table, so it applies only to certain sites. It seems like an uncommon option that should only be enabled exactly where necessary, with the user understanding what they are doing.

[icamps]

I think one solution would be to add a separate option for this in the extension settings. Users could disable this check if they want to. There might be cases where entering the password to a plain-text field is needed but Custom Login Fields might not work in that scenario.

That sounds good to me too.

[Flamefire]

One site where I found is the login site of https://www.payback.de

The "password" field looks odd:

<pbc-input type="password" name="password" autocomplete="current-password" id="passwordInput" label="Passwort" style="--input-validatable-container-margin-bottom: 1rem;"><pbc-input-password type="password" id="passwordInput__slotted" slot="input" class="pbc-input__input-component pbc-input" name="password" autocomplete="current-password"><input type="password" id="filed_0.21979__slotted" class="pbc-input__element pbc-input__element-password" name="password" autocomplete="current-password"></pbc-input-password></pbc-input>

[walkeral]

I've hit this problem as well, however there is something interesting about this particular site (British Gas). On any "working" site I can go "Choose a Custom Login Field", then click "Password", and I can see a grey shading box over the password field with "Password" in it. This also works fine on sites with separate pages for username and password (like Box). On this non-functioning site I get nothing at all, like it can't even see the field is there. I did have to enable "Allow Cross-Origin iframes" when I selected the username (this site does use separate pages for username and password).

[Flamefire]

On any "working" site I can go "Choose a Custom Login Field", then click "Password", and I can see a grey shading box over the password field with "Password" in it. This also works fine on sites with separate pages for username and password (like Box). On this non-functioning site I get nothing at all, like it can't even see the field is there

That's the same for me: It doesn't let me choose neither the username nor the password field on affected pages, i.e. no (in my case violet) shading with the text when hovering over the fields after clicking one of the manual select buttons

[JasonSome]

Reporting that this is still not working, and an example website is Chase's secure websites (not all of them, but whichever ones have a "Show" right next to the Password field). Same issue as @Flamefire, there's no shading when hovering over the fields.

[Malkierian]

Was just coming here about Chase myself. Same experience as JasonSome. https://secure07c.chase.com/web/auth/dashboard#/dashboard/overviewAccounts/overview/index

[varjolintu]

Was just coming here about Chase myself. Same experience as JasonSome. https://secure07c.chase.com/web/auth/dashboard#/dashboard/overviewAccounts/overview/index

This happens because the actual input is wrapped inside an element that steals the document.activeElement. The extension cannot know that you meant to select the actual child input.

[artlessconstruct]

Same problem for me on 2 websites:

1. archive.org password-only page used to access account settings: https://archive.org/account/index.php?settings=1
2. cloud.pocketbook.digital password-only page used to login: https://cloud.pocketbook.digital/browser/en

[ginkel]

I've got another page where this happens: https://business.ing.de/login/

[varjolintu]

2. cloud.pocketbook.digital password-only page used to login: https://cloud.pocketbook.digital/browser/en

This is not related to this issue at all. The input field is just not detected because.. there's a form, which has iframe inside it, and a document element inside that one.. Phew.

[varjolintu]

I've got another page where this happens: https://business.ing.de/login/

Not related to this issue either. The input elements are inside a nested Shadow DOM elements which we support only partially.

[varjolintu]

Just a reminder, that please read the issue description before commenting about issues that are not related. It makes my job easier.

[ginkel]

I've got another page where this happens: https://business.ing.de/login/

Not related to this issue either. The input elements are inside a nested Shadow DOM elements which we support only partially.

I'm sorry for not analyzing the cause before commenting. Would you like me to open a new issue or do you consider this broken beyond repair?

[varjolintu]

I've got another page where this happens: https://business.ing.de/login/

Not related to this issue either. The input elements are inside a nested Shadow DOM elements which we support only partially.

I'm sorry for not analyzing the cause before commenting. Would you like me to open a new issue or do you consider this broken beyond repair?

The correct place for these kind of detection issues is the dedicated pinned issue: https://github.com/keepassxreboot/keepassxc-browser/issues/1358

[varjolintu]

I made a simple fix for this. Give it a try if you can :)

[icamps]

I made a simple fix for this. Give it a try if you can :)

In version 1.9.1? If yes, here the problem remains.

[varjolintu]

@icamps No. The linked pull request has it.

[icamps]

@icamps No. The linked pull request has it.

Sorry my ignorance, but how do I test it?

[pzystorm]

One site where I found is the login site of https://www.payback.de

The "password" field looks odd:

https://www.payback.de is still not working. The username works. But the password not. It seems somehow related to iframes and the Google Recaptcha thingy which is at the bottom right of that page. Because whenever i try to fill in a password via KeePassXC magic, there is INSIDE this small Google recaptcha box a message from KeePassXC, that no passwords for www.google.com has been found.

Could you have a look?

[icamps]

Any update?

[droidmonkey]

What's to update? This feature works fine