Make it clear during setup process if the KeePassRPC plugin is going to be downgraded

[elieux]

This can happen for example if I upgrade KeePassRPC when Thunderbird's KeeFox is updated, but then I open Firefox which runs an older version of KeeFox.

A KeeFox setting to "not offer any upgrades or installations" would be a possible work-around and/or complement to this feature.

[luckyrat]

A newer KeePassRPC plugin is not necessarily compatible with an older version of KeeFox.

No doubt there have been some occasions where backwards compatibility would have been possible but I think those occasions would have been rare (especially in the stable, non-beta, channel).

Granted, this design decision was taken long before support for multiple applications existed so you certainly raise a valid concern about the lack of backwards compatibility and it's something I will bear in mind when working on some changes to the communication between KeeFox and KeePassRPC in KeeFox 1.3. However, I can't promise that there will be a way to retain backwards compatibility very easily so I can't commit to changes in this area just yet.

Adding an option to pretend that upgrades and installations are not required seems like something that will cause a lot of confusion - people do tend to click options without always fully understanding them (especially when reading non-native languages) so wherever possible I want to avoid creating options that could cause KeeFox to break for no discernible reason.

Would it help if the upgrade page offered extra information about exactly which version is going to be installed and why?

[elieux]

A newer KeePassRPC plugin is not necessarily compatible with an older version of KeeFox.

I understand that an older KeeFox version requires a corresponding, i.e. older version of KeePassRPC. I didn't mean to propose full backwards compatibility. The issue I was trying to point out was that KeeFox offers to upgrade KeePassRPC when it actually wants to downgrade it. It would be nice if KeeFox were able to tell the user if this is the case. Also, once it learns about this, it should instruct the user that they probably want to upgrade KeeFox instead.

this design decision was taken long before support for multiple applications existed

As a sidenote, it's possible that a user has got several profiles in Firefox (with differing versions of KeeFox). Or, that several users share an installation of KeePass.

Adding an option to pretend that upgrades and installations are not required seems like something that will cause a lot of confusion

I understand your concern. That request was mostly for me. Since I always upgrade KeePassRPC manually, the upgrade page is more annoying than helpful (see #166) to me. How about waiting with the upgrade page until the user click on one of the add-on buttons? The buttons would of course have to flash for a while, turn red, show an informative text on mouseover and whatnot.

Would it help if the upgrade page offered extra information about exactly which version is going to be installed and why?

Definitely. Even more if combined with the information I proposed in the first paragraph of this post.

[luckyrat]

How about waiting with the upgrade page until the user click on one of the add-on buttons? The buttons would of course have to flash for a while, turn red, show an informative text on mouseover and whatnot.

There are some disadvantages to that approach:

• User is forced to click somewhere to initialise KeeFox every time (we can't tell if an upgrade is needed until KeeFox has initialised) - I think this would be at best annoying and at worst so confusing that the user loses interest in learning how to use KeeFox.
• The focussed site restored from an old session won't be auto-filled

Definitely. Even more if combined with the information I proposed in the first paragraph of this post.

Yep that sounds good.

It's not actually possible to do this with the current KeePassRPC protocol but I'm working on an improved version at the moment so I'll bear this in mind when finalising the new version later this year.

[luckyrat]

I've renamed the issue to more accurately describe the changes I'll make in KeeFox 1.3. It sounds as though the extra information and suggested action should be enough to resolve this issue but we can always consider extra steps in future if it turns out to be insufficient.

[luckyrat]

This is implemented and working now on my dev build although it will be a little while before the rest of the v1.3 build is stable enough to test.