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.