Prioritising and sorting matched entries in Kee 3.5 and higher

Kee browser extension
21

Hi!

Priority override is very useful option. I have a lot credentials with the same url and want to choose which one will be used by default. Otherwise I have to spend time choosing manually. Sometimes miss.
Please make at least the ability to select one priority entry.
You can see that this is very important for many!

22

I just got another idea:

Wouldn’t it be possible to simply remember the last used login (which is enabled for aut-fill) for a domain/hostname directly in Kee?

1 Like
23

That’s an interesting idea. I’m currently working out a plan to develop features relating to the ways people used to use the Priority override so I’ll see if that can form at least a part of the solution.

1 Like
24

I’ve outlined below a set of new features and implementation tasks that I think will address the concerns raised here so far. Please let me know if you agree and share your views on the relative priorities of each feature.

They’re listed in order of how likely I am to donate my time to implement them, from high to very low. If you want to help accelerate the implementation of these ideas (even the top one since I won’t have time to start implementation on this for at least a couple of months), please let me know.

1) Add UI to matched entry card for configuring match preference

  • Allow matched entries to render differently to non-matched entries - perhaps implicitly via a true/false/undefined flag to indicate if the entry is the current preferred match.
  • Add a new row underneath current card contents with a star icon button and label: “Preferred matching entry”
  • Tooltip upon hovering over the star icon button: “Make this my preferred entry for this website”
  • Clicking the button will behave as described below.

if this entry is the current preferred entry:
    1. remove all config settings that can make it the current preferred entry (all Domain, hostname and page settings that specify this entry’s UUID)

else:
    1. if another entry is the current preferred entry remove all config settings that can determine the current preferred entry if they are equally or more specific than the configured target
    2. create a new “Exact method” per-site setting to record the UUID of the entry using the configured target

* if feature 3 has not been implemented: configured target = Domain

When removing an existing setting, we’ll either remove just the preferred entry UUID or, if we can determine that no non-default options are in use for the specific site configuration, we can remove the entire per-site configuration for the target and value in question.

2) Use preferred entry for auto-fill/submit even if it is not the best match

We should already have access to the relevant config in formFilling.ts once feature 1 is complete so the changes should be fairly simple:

  • This only overrides automatic form filling/submitting; manual submission is unaffected
  • All the usual decisions regarding entry behaviour are observed. E.g.
    • marking an entry as preferred will not change that entry’s auto-fill/submit behaviour
    • preferred entries that are a very poor match for the form will not be auto-filled

3) Add per-site configuration for which target to use for preferred entry setting

Label: "Preferred entry setting applies to : " Domain, hostname, page (dropdown / radio buttons)

Explanatory note: “Only affects new preferences. You can change existing preferences by choosing a new matched entry next time you visit the site.”

Need to watch out for conflicts with upcoming work on replacing the current options page with a VueJS approach.

We can end up with multiple records for each web page - e.g. page, hostname or domain. In theory, advanced users could hack into the underlying config data to set up even more complex systems involving prefix and regex methods too. We must therefore plan carefully how to manage this situation for users. The main question is whether to delete any existing configurations when an entry is marked as the preferred entry for a specific URL. Deleting always could prevent some advanced configurations such as a default entry for the entire domain but overriding that choice for one or more specific hostnames. Not deleting will lead to a proliferation of hidden useless data in the configuration and no doubt some complicated steps for users to complete in order to achieve certain desired reconfigurations. I think the compromise outlined in feature 1 will minimise potential confusion and at least allow for a “reset” by deselecting and selecting the preferred entry on each related site if any advanced configuration or changes to the PSL cause problems in future.

4) Tell the user when a per-site configuration has hidden settings

Some per-site configuration can’t be viewed or edited via the main options page. Assuming this holds true after rewriting in VueJS, we should include a notice that explains when these settings are present so that users don’t “tidy up” seemingly unused configurations, potentially breaking features such as the “preferred entry” for a website.

5) Add per-site configuration for matched entry sort order

New setting: “Sort matched entries by:” Best match, title, username (dropdown / radio buttons)

Explanatory note under the setting: “This has no impact on which entry is auto-filled or auto-submitted”

It shouldn’t be too hard to make this sort order apply to both the old and new matched entry ordering so the only thing to watch out for is whether working on the old iframe panel view is a waste of time if it will be removed before this feature gets released. Similarly, need to watch out for conflicts with work on replacing the current options page with a VueJS approach.

6) Automatically make selected matched entries the preferred entry for a website

  • New boolean option: “Automatically make any selected auto-fillable entry my preferred entry for a website”. Feature will default to off.
  • Selecting a matched entry from either in-page or popup matched entry list will create or update a new “Exact method” per-site setting to record the UUID of the entry using the Domain target, as long as the entry does not have a “Never auto-fill” setting.
  • This feature will be removed once feature 1 is developed because I expect the automatic nature of this to become increasingly counter-productive once a manual configuration alternative is available so I wouldn’t want this sort of “magic” happening in the long-term. It’s also too simplistic to cope with changes to the PSL (public suffix list); while rare, this could lead to problems over time which precludes us from offering this feature even as an option once we next update our bundled version of the PSL (usually with each Kee release but it can be delayed for a few months or even a year with minimal impact).
  • This would depend upon feature 2 and a simplistic version of the per-site configuration settings removal algorithm outlined in feature 1.
  • @pasbec, given the above drawbacks, I’m not convinced it’s worth anyone spending the time on this idea but it is going to be slightly less work than the full implementation of feature 1 and 2 so if anyone really wants to take it on, that’s OK with me.

PS: I’m updating the topic title to help draw attention to these issues.

25

Dear Luckyrat,
Many thanks for listening to opinion of users on the importance of prioritising entries.

For me, the most useful option would be ability to set the preferred entry among all entries with the same URL or nearly the same URL. This entry should be auto-fill on the website by default.

I vote for option #2.

26

Just my 2 cents worth here. I don’t use the auto-fill feature for exactly that reason. I don’t want it to fill until I select the correct one. I have several sites with 3 or 4 logins. It is a simple matter to choose the correct one when the username is displayed in the list anyway.

27

Adding a search field at the top of the popup menu which opens when you click the username/password/whatever field would be a perfect solution!
Something that filters through usernames (imagine multiple gmail accounts) or page titles.

1 Like
28

I’ve now dealt with 1, 2 and 4 from the list of new features I posted above. They will be included in Kee 3.6. I’ll release a beta in around 1-2 weeks so make sure you’re using the beta version in Firefox if you can and when you get the update, please let me know what you think.

6 will not be implemented since it’s now redundant.

I intend to develop 3 after Kee 3.6 has been released for some time, to avoid introducing this additional complexity too soon. Thus it’s unlikely to be released this year. https://github.com/kee-org/browser-addon/issues/276

I have no plans to implement 5 this year but it’s probably not a big task so I’d either accept a PR from someone else for Kee 3.7+ or might be able to find time to look at it in 2021, but no promises. I’ve added it to GitHub issues so feel free to assign yourself to implement it if you’d like to see it supported earlier. https://github.com/kee-org/browser-addon/issues/283