Kee & filling in fields

#1

While Kee works nicely overall, there’s one problem I’ve recently noticed … Kee should NEVER automatically replace field contents when there is already content in a field, especially not if it’s input that wasn’t loaded by the page, but typed by the user …
I’ve been in a forum where Kee by mistake thought the message entry was the username, and after switching a tab and back, replaced my typed message with my username … thanks a lot!
The option to block certain entry fields from being filled is not really helpful, as the next web page I might visit could cause the same behavior all over again …

#2

Thanks for the feedback and sorry that you lost that message!

We did have an option to control this behaviour many years ago but there were far too many websites on which it would prevent auto-fill from working - they would prefill the fields with placeholder text and clear it when the user clicks in the field.

We probably could monitor every field on the page to detect when someone types into the field and prevent auto-fill once someone has manually entered text.

I’m not sure I would go as far as to say we should avoid auto-fill when the web page has pre-filled the content, although perhaps the web has changed enough by now that this can also be considered.

In the mean time, you can disable auto-fill (and just manually ask Kee to fill in the details when you want) either for all entries (in Kee Options) or individual entries (in the entry configuration in Kee Vault/KeePass). The latter approach doesn’t help if this happens on several websites you use and although this appears to be a rare problem it totally sucks when it happens so I can understand why you’d be wary.

#3

In Kee 3.2, we will track the initial value of every form field as we scan them (when the page first loads or when the page dynamically inserts a new filed at some later point).

If a form filling operation was automatically invoked (e.g. when changing tabs as in the case you reported here) we will only fill the field if it is unchanged from its initial value. When filling a value, we will consider that to be the new “initial” value. This information won’t affect the selection of suitable form fields or the decision about which entry best matches the available forms. Perhaps we will find some accuracy improvements from doing so in future but that’s far from certain so I’ll keep this feature narrowly focussed, at least to start with.

If a form field is re-created by a web page, using user-supplied text, in a way that can’t be easily re-initiated by the user, there is still a risk of data loss. For example, one can imagine a form field that gets deleted and re-created every time a user types a character into the field. In this case, depending upon the exact timing of various operations, we could detect that the form field has not been modified and is therefore safe to overwrite. I don’t currently see any way to avoid this risk, but I suspect it is such an edge case, with such a serious performance penalty to any website that is developed using this approach, that we won’t see this theoretical problem on any real websites :crossed_fingers:

There’s a required subtle tweak to the form saving behaviour too: The user should be prompted to save/update the password if the submitted value is different from the one that we filled in, or would have filled in if it weren’t for the user modifying the field contents in the mean time. Hence, if the user continues to modify the form field after the aborted attempt to automatically fill the field, they will not be prompted to save the modified password unless the final value of the field is different to that of the entry that was most recently chosen to be filled into the form.

I think this improvement will strike a decent balance between the automatic fill operation still occurring when people expect it to, and not accidentally overwriting content.

#4

I’ve noticed some similar behavior but with much more impact.
Since Kee filled in fields from keepass to login-fields on defined loginpages only, some releases ago the process seems to have changed.
Kee now replaces also data from subpages after the login.
This is really an issue e.g. for admininterfaces, where users firstnames are replaced by your adminaccount name. e.g in Exchange, this will also result in changing users primary emailaddress.
We had to disable kee to prevent unwanted changes in several admin-portals.

#5

I’m not sure what happened some releases ago but it’s always been the case that automatic fill operations could misidentify form fields that look just like a login form. We’ll keep improving that behaviour in the coming years but it is impossible to solve in 100% of cases so we have to be realistic - hence the wide array of ways that you can control the behaviour of Kee on specific websites and with specific entries.

You can disable automatic form filling across all of Kee while still being able to manually ask for the form to be filled in - it’s fast to change that option but probably unnecessary. Search the options in Kee and KeePass/Kee Vault and on this forum and you’ll find many other ways to configure the behaviour just for this specific problematic website.

#6

thanks for the quick reply.
disabling automatic formfilling will most likely work for us. Will try.
I don’t wan’t to risk modifying entries for specific sites - this didn’t only occur in one site.
Actually, if you use this for admin work, behind most logins there’s any kind of form.
thanks for the hint.