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)
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.