1191870 - Attempting to update an add-on fails with an unspecific error message if the update is also unsigned

Status: RESOLVED INACTIVE

(Toolkit :: Add-ons Manager, defect, P3)

Description

[Dave Townsend [:mossop]]

If you go to the add-ons manager and try to update an add-on that has an update available but the update is unsigned it fails and displays the message "There was an error downloading <add-on>. Try Again"

We might want to display a more specific message here, what do you think Markus?

Comment 1

[Markus Jaritz [:designakt] (UX)]

Can we not show the update and with that prevent the need of an error message being shown at all?
I mean even if we have the best possible text, it is still us providing the users with an option (update), just to tell them a second later that this option is not possible. We should not do that.

For me to get a better picture, could you share a screenshot, or share how I can reproduce the error?

Comment 2

[Dave Townsend [:mossop]]

Attachment: screenshot

There are two cases.

If the user has automatic updating available and decides to go to the add-ons manager and choose to check for updates we show a download progress for the update and then end with the error message above.

If the user doesn't have automatic updating available and checks for updates then we say an update is available, the user clicks to see it and sees the new update and click update and we then again show the download progress and then the error.

The final error message is attached.

Comment 3

[Dave Townsend [:mossop]]

For the first case there isn't much we can do other than change the error message. We don't really advertise an update available as such.

For the second case I guess we could download all updates before telling the user they are available.

Since the second case should be rare (it's a non-default option to use manual updates) I'd rather just figure out a new error message for now which will cover both cases somewhat since we might be able to get that in before the merge.

Comment 4

[Markus Jaritz [:designakt] (UX)]

OK, this does not sound optimal.

If we need to have an error message, I would recommend using the one we already have, and I do not see much help in talking about the update in detail as the add-on will stay disabled anyway.

<add-on name> could not be verified for use in <Product> and has been disabled. More Information

I assume we will keep the last unverified update of the addon, show the new version number, and new date of last update in the details view, so one interested in the details can see that it is a new version, but still unverified.
And a user not interested in the details will see the unverified message, an update, and the unverified message again, indicating that it is still unverified.

Comment 5

[Dave Townsend [:mossop]]

(In reply to Markus Jaritz [:maritz] (UX) from comment #4)
> OK, this does not sound optimal.
> 
> If we need to have an error message, I would recommend using the one we
> already have, and I do not see much help in talking about the update in
> detail as the add-on will stay disabled anyway.
> 
> <add-on name> could not be verified for use in <Product> and has been
> disabled. More Information

This isn't necessarily an accurate message though. We could see a case where the user has a verified add-on installed and then the verified isn't signed for some reason (developer error perhaps) in which case the existing add-on will remain enabled and we just won't install the update.

> I assume we will keep the last unverified update of the addon, show the new
> version number, and new date of last update in the details view, so one
> interested in the details can see that it is a new version, but still
> unverified.

No, we won't install an update if it isn't verified, we'll just keep whatever version the user currently has.

Comment 6

[Markus Jaritz [:designakt] (UX)]

(In reply to Dave Townsend [:mossop] from comment #5)
> This isn't necessarily an accurate message though. We could see a case where
> the user has a verified add-on installed and then the verified isn't signed
> for some reason (developer error perhaps) in which case the existing add-on
> will remain enabled and we just won't install the update.

So, this is very restrictive, but there are different cases now:

One where a working add-on can not be updated, because the update will break the add-on:
Yellow message, add-on active:
The update to <add-on name> could not be verified for use in <Product>. <add-on name> has not been updated. More Information

And one where a broken add-on stays broken, and therefor the update is not as relevant but only way to mention it is this message.
Red message as the add-on itself is still unverified, add-on deactivated:
The update to <add-on name> could not be verified for use in <Product>. <add-on name> has not been updated. More Information

I would like Matej to review the new update message.

> No, we won't install an update if it isn't verified, we'll just keep
> whatever version the user currently has.
Why is that?

Comment 7

[Dave Townsend [:mossop]]

(In reply to Markus Jaritz [:maritz] (UX) from comment #6)
> > No, we won't install an update if it isn't verified, we'll just keep
> > whatever version the user currently has.
> Why is that?

We're set up to refuse to install add-ons that are unverified, the update is unverified so we don't install it. The fact the user already has an unverified add-on installed is a holdover from before we added the signing requirements.

Comment 8

[Matej Novak [:matej]]

(In reply to Markus Jaritz [:maritz] (UX) from comment #6)
> (In reply to Dave Townsend [:mossop] from comment #5)
> > This isn't necessarily an accurate message though. We could see a case where
> > the user has a verified add-on installed and then the verified isn't signed
> > for some reason (developer error perhaps) in which case the existing add-on
> > will remain enabled and we just won't install the update.
> 
> So, this is very restrictive, but there are different cases now:
> 
> One where a working add-on can not be updated, because the update will break
> the add-on:
> Yellow message, add-on active:
> The update to <add-on name> could not be verified for use in <Product>.
> <add-on name> has not been updated. More Information
> 
> And one where a broken add-on stays broken, and therefor the update is not
> as relevant but only way to mention it is this message.
> Red message as the add-on itself is still unverified, add-on deactivated:
> The update to <add-on name> could not be verified for use in <Product>.
> <add-on name> has not been updated. More Information
> 
> I would like Matej to review the new update message.

Looks good to me. Thanks.

Comment 9

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.