Form field type "radio" instead of "username"

Hi,

I’m using Kee with Firefox. Frequently, I’m having the problem that on a login page, the password is automatically inserted, but the username is not. The little icon is shown in both fields (username and password), I click it, select the (only) entry, and then it is filled in.

When I look at the entry in the KeePass application, under “form fields” there is the following:

name: passwrd
value: KeePass password
id: password
type: password

→ That seems to be fine.

But then:

name: username
value: KeePass username
id: username
type: radio (!)

→ What is the “type radio” doing here?

When I try to edit the “username” entry, the type field is disabled (greyed out), but empty. In comparison, for the “password” entry the field is also disabled, but is saying “password”.

This happens all the time, on different websites. On others (most) it works fine. What can be the reason for this?

Regards

same problem here, struggling to resolve reference entry problem, the solution mentioned in https://forum.kee.pm/t/placeholder-handling/1100 doesn’t work when enable placeholder feature for individual form fields because of new “radio” field type.
KeePassRPC version is 1.15.1.0.

it seems to be a bug for KeePassRPC v1.15.1, problem solved after downgrade KeePassRPC to v1.14.0

The only related thing changed in v1.15 that I can see is that we now enforce that the “field type” dropdown box will behave more like a typical drop down box. None of that should actually change the field type though - just make it impossible for accidental changes to occur in future.

@150d are you using the latest version (1.15.1)? Perhaps the affected entries were edited using an older version of KeePassRPC and they sufferred from accidental adjustment of their type configuration. It’s also possible that they are just being shown as “radio” in the UI if they have no type information associated with them.

I can’t reproduce the problem with existing or new entries so we’d need to find a way to do that before we can identify if there is a current bug that needs to be fixed. Hopefully, no matter what might have caused the issue previously, just recreating the entry using the latest version of Kee will resolve it for each of the affected entries. Technically you could also inspect the KPRPC JSON advanced string field and see if there is a difference with the broken and working entries and attempt a manual fix but that’s unlikely to be much quicker than just saving the entries again from scratch, unless you have a lot of additional information in the old entries that will be a pain to move across.

I am using the latest beta of the Kee browser addon - Release 3.11.10 · kee-org/browser-addon · GitHub. Although I doubt that will make a difference it might be worth trying that just in case.

I’m not sure if @RRRainick 's issue is related at all to this topic. Please look for other discussions about placeholders to see if anything else can help.

Thanks for following up on my issue.

Currently, I’m using KeePass v2.54, KeePassRPC v1.15.1 and Extension v3.10.10 with Firefox v115.3.1esr (64bit).

The issue of “sometimes not filling in both fields” is an old one which I just got into investigating again. On the one hand, many of my entries have definitly been created with previous versions. On the other hand, when I recreate one of the entries I’m currently working on with this combination of versions, the new entry is created exactly like that again.

It’s also possible that they are just being shown as “radio” in the UI if they have no type information associated with them.

I feel this might well be the case:

Rechecking the entry in question just now, in the tab “Form fields” the display is now correct: Id “username” shows type “username”, just as id “password” shows type “password”. However, when I click the “Edit” button, in the dialog “Edit form field” the (disabled) combobox for password does show type “Password”, while the same dialog for username shows type empty. The type “radio” is not shown any more anywhere (but that might have gone away by recreating the entry.)

For reference, I’m currently testing with this website:

https://monitoring.solaredge.com/

Regards

I’m getting the same problem – and the same solution fixes it.

KeePass 2.55 (64-bit), KeePassRPC 1.15.1, Firefox 118.0.2 (64-bit) with Kee extension 3.10.10.

With those versions if under the Kee - Form fields tab I double click on the “username” entry the Type dropdown is disabled and empty, and if I then OK the dialog box the type in the list of form fields changes to “radio”.

If I roll back KeePassRPC to v1.14.0 then everything works fine and as it should, i.e. the Type dropdown is still disabled but it says “username” (and stays that way after OKing).

Thanks for the extra information @mc2

I can now see that clicking OK to save a change to the form field configuration using the latest KPRPC version causes a problem.

I don’t have any idea why it happens or how to fix it yet but in the mean time, please can you try following the instructions below on an affected entry to confirm that this then causes Kee to behave as expected?

To repair any affected entries, you can edit the “KPRPC JSON” advanced string - replace the “FFTradio” “type” with “FFTusername”, for the JSON object containing the “value” of “{USERNAME}”.

Make sure this is the only thing you change while the Entry Edit window is opened, since this will simplify rolling back to an earlier version of the entry if anything goes wrong.

For example, if your JSON is like this:


{"version":1,"hTTPRealm":"","formFieldList":[{"name":"password","displayName":"KeePass password","value":"{PASSWORD}","type":"FFTpassword","id":"password","page":-1,"placeholderHandling":"Default"},{"name":"username","displayName":"KeePass username","value":"{USERNAME}","type":"FFTradio","id":"username","page":-1,"placeholderHandling":"Default"}],"alwaysAutoFill":false,"neverAutoFill":false,"alwaysAutoSubmit":false,"neverAutoSubmit":false,"priority":0,"altURLs":[],"hide":false,"blockHostnameOnlyMatch":false,"blockDomainOnlyMatch":false}

Change it to this:


{"version":1,"hTTPRealm":"","formFieldList":[{"name":"password","displayName":"KeePass password","value":"{PASSWORD}","type":"FFTpassword","id":"password","page":-1,"placeholderHandling":"Default"},{"name":"username","displayName":"KeePass username","value":"{USERNAME}","type":"FFTusername","id":"username","page":-1,"placeholderHandling":"Default"}],"alwaysAutoFill":false,"neverAutoFill":false,"alwaysAutoSubmit":false,"neverAutoSubmit":false,"priority":0,"altURLs":[],"hide":false,"blockHostnameOnlyMatch":false,"blockDomainOnlyMatch":false}

@RRRainick I think you can apply a similar fix after modifying the placeholder setting for an entry.

As well as understanding how to prevent the “type” being changed unexpectedly, we will probably also need an additional fix to handle any entries that have become corrupted in this fashion (especially useful for anyone that doesn’t know they have hit this bug). That might be do-able as a one-off data migration task or perhaps have to be rolled into the larger project of our review of form field configuration in this issue: New Entry configuration format · Issue #101 · kee-org/keepassrpc · GitHub

Well, I don’t believe I have any actual affected entries as I rarely find the need to change the form fields, but having had that rare need on Saturday I spotted the problem straight away, did a search, found this thread, and straight away downgraded to KeePassRPC v1.14.0. :wink:

But, sure, on temporarily going back to 1.51.1 and editing an entry as described then, yes, after OKing the KPRPC JSON string then shows FFTradio and changing it to FFTusername does result in the username entry in the Form fields tab showing as type username again.

But if I then edit that form field again I’m back to square one, with the Type dropdown being disabled and empty, which I think is probably the real problem (or, at least, the visible manifestation of it).

No update on this then? Obviously not as KeePassRPC 1.15.1 is still the latest version.

I’m happy enough running v1.14.0 on my PCs for the moment but I expect that eventually I’ll want to upgrade to some future version, and I wouldn’t want this bug to still be there. :slight_smile:

It does sound from your Oct 23rd reply that you’ve at least reproduced the problem, so I’m not sure what I could do to help you track down the issue, but if there is anything …

The fundamental problem was that by fixing the group of bugs that came from being able to manually enter any field type to the type dropdown we also prevented some of the weird custom behaviour relating to the “Username” type.

I’ve found a different way to implement that custom behaviour which should be compatible with the other bug fixes too.

Please try version 1.16.0 from Release 1.16 · kee-org/keepassrpc · GitHub.

Just opening any broken Field in the Form Field editor and clicking OK should repair an affected field (save your database to see a change in Kee).

In a future version I’ll automatically fix up all KeePass Username fields that ended up with a “radio” type but that depends on a lot of other work (mostly in the previously mentioned issue #101).

Thanks for the offer of help @mc2 - testing out the new version would be very helpful. If everything is looking good I’ll probably promote from beta testing early next year and push out the update notification a few weeks after that.

Ok, well I’ve installed v1.16.0 and on a quick and cursory test is appears to work. The only slight inconsistency is that the username entry shows as type “Text” in the disabled Type selector rather than as type “Username” as it did before (under 1.14.0). It does, however, show as “username” in the Form field tab list, even after adding/editing the field.

I’ll stay with 1.16.0 and report if I have any problems with it.

1 Like