First and foremost: Luckyrat, I cannot describe how useful and brilliant your software has been for me over the years. THANK YOU for all your work.
I am only getting used to the latest version of Kee and again: You have done a tremendous job.
Unfortunately the new Contextual Kee Icons show up in a lot more form fields then they should for my liking. (Consider the attached screenshot: The contact form has no fields that would require an interaction with Kee.)
Is there a way to configure the behaviour and placing of the contextual icons?
I agree that that having those Kee icons appear in form fields that are clearly not username or password fields is distracting. This is definitely more prominent in Kee than it was in KeeFox because of the way the icons are presented in each field.
One way you can limit the forms that Kee tries to fill is by changing the Minimum URL Match Accuracy for your Keepass entries. Open an entry in Keepass, then go to the Kee tab, choose the URL tab and change the URL match accuracy to something stricter than the default, which is domain matching, In this way you can limit the Kee match only to those pages that have login forms. Of course, if the website changes its login URL or has multiple login URLs, stricter matching might prevent Kee from recognizing those pages. I use this mostly to segregate different hostname entries, i.e., my.hostname.com vs. support.hostname.com, but I do have a few entries set to Exact.
Another way you may be able to limit those is by adding those form or field names and ids to the Kee options blacklist, but I confess I haven’t really experimented with this yet as Kee is still evolving and I don’t want to get ahead of myself and complicate matters.
Unfortunately the login form is located on the same page, so changing the URL Match Accuracy will not help.
I have thought about that as well but just like you, I haven’t had time to play with those settings yet. Also it would be good to know about the format used for those lists, i.e. wildcards etc. and to be clear about the behaviour of those lists beforehand. I would expect something like:
White list – these fields/forms will definitely be handled
No list – these fields/forms might be handled (or excluded – this is important), but not with certainty
Black list – these fields/forms will be excluded
@Megamind: You wouldn’t know about those list issues by any chance?
To be clear, I have added a couple of specific entries to the White List fields for ‘Text Field Name’ and ‘Text Field ID’ in order to get one or two forms working that Kee was ignoring. The result was successful and consistent what you expect. What I haven’t done is use the blacklist, as I wanted to have time to do some testing and think through the impact any additional entries might have on other sites. Also, I only have a small number of sites with with the issue you describe, so I it would probably be safest for me anyway to make any blacklist setting site-specific.
I’m doubtful that wildcard entries would work if only because the default entries already contain so many variations of names like user* (username, userID, etc.) and no wildcard was used to define them.
The blacklist approach could work but I wouldn’t recommend it for the sort of widespread adjustment of behaviour requested here - it’ll be either time-consuming for you to maintain the lists or result in failed logins.
Probably best to instead discuss what sort of configurability should be added that is specific to the Kee icons since that seems to be what is causing concern?
I agree with both of you, @Megamind & @luckyrat: Any variant of using the blacklists would undoubtedly mean intense maintenance.
Personally I would prefer an option to configure the buttons themselves. Sidetrack : That being said, I would also recommend to have two views for the options-dialogue: 1. The initial really short basic set of options, as is the case right now. 2. An additional wide ranging advanced set of options that has to be opened separately.
Then there is the actual option for the contextual buttons themselves. For me a simple on/off switch would do the trick, as I never really use the button-feature. But I feel that this would be counter-productive to the evolution of the software.
Maybe a selectable option to restrict the contextual buttons solely to the whitelist and not show them anywhere else would be a better approach?
This is a big issue for me; It seems that the contextual icons show up all the time, which makes filling in forms with a lot of fields very annoying (especially small fields.) I’ve narrowed it down to an overly permissive whitelist, specifically the name/id of “id” and “email”
I would suggest one of the following:
Don’t put the icon on every field in the form; try to target just the auth fields.
Only attach it to every field if the form name or ID matches one of the whitelist items
Don’t match on hidden fields (this seems to be what often triggers the behavior)
Expose a way for us to see what field triggered the match
The issue below is potentially related. Needs more planning to establish if there should be independent configurability for the contextual button and form filling but we need to at least consider the overlap.
Generally I like and use the contextual buttons a lot.
But I have two problems with them showoing up on many (or all) input und textfields
For my personal use I could not get blacklisting to work, the contexual button always show up. I tried form id and texfield-id.
On our website, our users often edit their data. After login all users with kee see the contextual buttons in any input and textfield. I tested this also with a new keepass database with only one login.
Therfore I would highly appreciate a more sensitive / defensive approach, that would not need any interaction of the user.
For anyone still looking for a quick workaround for this while we work out what larger scale changes to implement, the new draft documentation about using blacklists might be of interest.
