Closed Bug 1167920 Opened 10 years ago Closed 3 years ago

Provide better feedback to the user when add-ons are disabled on upgrade

Categories

(Thunderbird :: Add-Ons: General, defect)

Product:
Thunderbird
Component:
Add-Ons: General
Version:
38 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(thunderbird_esr38?)

Status:
RESOLVED INCOMPLETE
Tracking Flags:
Tracking Status
thunderbird_esr38 ? ---

People

(Reporter: unicorn.consulting, Unassigned)

References

Details

This is in many ways a Dup of bug 775623 but I am filing this in the context of the 38 Beta. It would appear that in this somewhat edge case of downgrade from Daily the Lightning add-on that is bundled is not installed and in fact Lightning is disabled. This may well be a weakness in the search for updates that only searches for higher version numbers, rather than compatible versions, but I am only guessing.
tracking-thunderbird38: --- → ?
tracking-thunderbird_esr38: --- → ?
Blocks: TB38found
I don't think it's specific to bundling though. It's always been the case that if you upgrade an extension that doesn't automagically downgrade in case you want to go back to the older app version. And if it's incompatible, it will disable itself.
I agree, Dup if you want. It is however worth noting as downgrading from the beta to release channel will I assume have the same issues. Perhaps what this bug should be about is not fixing the issue. Bug 775623 is to address that. I think this bug should address informing the user that manual intervention in add-ons, including the bundled calendar, is required. The existing test/update add-on dialog does not make it clear enough that the add-ons will be disabled. My suggestion is, on failure to locate updates to add-ons. We drop the user into the add-on manager where what is disabled and what is not is clearly displayed. It also addresses the issue of discoverability. The user is where they need to be to look at the issue.
tracking-thunderbird38: ? → ---
Summary: installed 38 Beta6 Lightning 4.3a1 installed add-on update disabled lightning. → Provide better feedback to the user when add-ons are disabled on upgrade
Component: Installer → General
Component: General → Add-Ons: General

Is this effectively fixed via bug 1574183? Or are side issues like bug 1505637 related?

See Also: → https://bugzilla.mozilla.org/show_bug.cgi?id=1505637

Downgrades are no longer possible and there is a big yellow message telling the user, that an add-on has been disabled because it is incompatible on app upgrade. With Bug 1713761 we link to the extension finder to search for alternatives.

If there are no objections, I will close this bug.

Close it if you like John, my concern is users appear in support looking for functionality that disappeared on update because it was previously provided from an addon. In some cases, it is only after they are pointed to a replacement addon that the penny drops that they used to have an addon.

I would like to see a dialog in the update process that specifies which addons have been disabled for compatibility reasons. We used to have such, and at the time users wanted to know why we did not offer to abort the update as their addons were not compatible. A not unreasonable position from most peoples perspective, just not thunderbird developers perspective. Apparently user choice does not extend to choosing not to update when it is offered.

Regardless we are not doing a good job of informing the user of the result of their update and as usual, support carries the weight of failed user communication.

I am not trying to shut down discussions, but merely trying to close bugs which are no longer relevant.

The request regarding pre-update user feedback is covered in Bug 1531786.

This bug is about issues caused by downgrades, which are no longer possible.

In your last comment, you pointed out the issue of functionality provided by an add-on going missing, when the add-on is disabled on app update. Do you consider this a separate issue, not covered by pre-update user feedback (bug 1531786) and also not covered by post-update feedback (bug 1713761 )? If so, can we still close this bug and you create a new bug describing the issue, the impact on support and how it could be solved (if you have a suggestion/idea)?

Downgrading is no long supported so, so I will close it myself. But just remember that there are significant levels of advice being given on how to rename files and use command line switches to do exactly that. Downgrade.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE

Would it help to (optionally) create profile backups on app upgrade?

(In reply to John Bieling (:TbSync) from comment #8)

Would it help to (optionally) create profile backups on app upgrade?

I would say yes, but for such a thing to be truly useful, it should be included with a profile backup and restore function. We should not be expecting users to copy and paste files, use obscure command-line arguments or for that matter be able to find about:profiles hidden in the masses of information in the troubleshooting informant. To restore a profile thunderbird should recognize a profile folder when it is pointed to one and just import it to the standard location defined for that device and offer to use it.

You need to log in before you can comment on or make changes to this bug.