Thanks for the suggestion. I think you’re correct that no one else has suggested this improvement before and there is definitely a strong argument for improving the workflow in this situation.
When an entry is edited from a different URL within the same domain, you’re right that in some cases it would be undesirable to modify the primary URL because it would change the URL to be the “change password” page. In other cases, it would be desirable to modify it because it will be changing to a new “sign in” page.
Kee currently assumes that the latter approach is more frequently used and therefore changes the URL but this approach is probably only more frequently used as a result of the historical behaviour of Kee and other password managers and an assumption that users change passwords less frequently than websites change their sign-in pages - hopefully this assumption is less accurate now than in previous years!
Only saving a new password once one has signed-in using it is no longer the best approach possible so I should have given the alternative approaches more consideration at the start of the year when we were planning the changes that made it into Kee version 3.5.
Unfortunately, I don’t think it’s feasible for us to automatically make the correct decision unless we can also be certain whether the edit is as a result of a change password form submission or a sign-in submission. Identifying the difference between those types of submission is not yet possible. I’m hopeful that some dedicated effort on that task would now be able to achieve this for at least some websites, but I’m far from sure how much work it would take nor what proportion of websites it could be made to work for.
Given that reliably knowing the difference between a password change form and a sign-in form would enable so many other improvements to the password management user experience, I think any significant effort to improve the workflow you’ve mentioned would be best spent on that larger goal.
However, a user option might bring a slight improvement more quickly than those efforts can succeed. I am wary of introducing too much content to the update user interface though so I’d prefer to find a way to improve the workflow without burdening every user with additional options to understand.
One idea might be to include a broader extension option so that those users who most often use the save-after-sign-in approach can select one automatic behaviour and those that tend to take the save-after-password-change-submission approach can select the other.
Of course, if you can tolerate having an inaccurate primary URL for the first sign-in after changing the password, you could edit the entry again after the next sign-in, which would not only fix up the URL but also ensure that any hidden information such as form field names and IDs remain accurate for the sign-in form rather than the change password form (and here is another area where we could really help users if we knew the difference between these types of form!)
Finally, make sure you try out the recent beta release since there’s a new feature which can show a button to directly open the recently edited entry; it would still take you out of the browser but it should be a quicker route to being able to modify additional information in the entry or undo changes like this undesirable URL change where Kee has been too clever its own good!