Closed Bug 488903 Opened 13 years ago Closed 11 years ago

Firefox should inform that an installed addon is experimental and automatic updates are disabled for experimental addons.

Categories

(Toolkit :: Add-ons Manager, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: TheOne, Unassigned)

Details

(Whiteboard: [amo:want P2])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8

When Firefox checks for updates for experimental addons, it returns "No updates were found", even if there is one.

Of course I know, that automatic updates are disabled for experimental addons, and that there is a good reason for that. No need to discuss that.

But most of the users don't know that! Cause they don't even think about that. They logged in (or checked the checkbox) on AMO and downloaded the addon, but it's not really obvious that they won't get any updates for them.

Telling the user that there are no updates is actually wrong, even when regarding that automatic updates are disabled. It's a big difference, if something is just there or you have to get that something yourself!

So, my proposal is: Don't say "There are no updates." when checking.
Say something like: "This addon is marked as experimental. Automatic updates for experimental addons is disabled. Please check for an update yourself."

Users who use experimental addons will use the extension manager too, and they will read that there.
Or just add some sentence like the one above in the addon install dialog for experimental addons.

But just saying nothing about that is the wrong way. Especially the wrong way to get the addons reviewed on amo for getting out of the sandbox.
Because users don't know of maybe bugfixes or improvements, and if they are annoyed enough with some maybe old and in newer versions already fixed bug, they will just uninstall the addon instead of looking for a new version.

Reproducible: Always
Sending this over to AMO. Firefox doesn't have any way to know that AMO isn't going to offer updates for a particular extension, this is really something that AMO would have to include some not about I think.
Component: General → Public Pages
Product: Firefox → addons.mozilla.org
QA Contact: general → web-ui
I agree that AMO should do a better job of informing the user about this, but I also wonder if we could have another message like "Updates must be manually obtained for this add-on" that displays when:
1) there is no updateURL for the extension and the default AMO check returns that the add-on isn't hosted on AMO
2) the add-on is in the sandbox and no updates are provided

Thoughts on that, Mossop?
(In reply to comment #2)
> I agree that AMO should do a better job of informing the user about this, but I
> also wonder if we could have another message like "Updates must be manually
> obtained for this add-on" that displays when:
> 1) there is no updateURL for the extension and the default AMO check returns
> that the add-on isn't hosted on AMO
> 2) the add-on is in the sandbox and no updates are provided

Right now there is no way for Firefox to determine either of these things. It's not impossible for us to come up with a spec that might allow for that, but I'm not sure what level of reward we are talking about here. I have no stats to go on but my guess is that the majority of users simply never manually check for updates.
Incidentally do the upcoming sandbox changes make this a non-issue anyway?
(In reply to comment #3)
> Right now there is no way for Firefox to determine either of these things. It's
> not impossible for us to come up with a spec that might allow for that, but I'm
> not sure what level of reward we are talking about here.
> 
Yeah, I know it's not currently possible. I was thinking of a response or header that could be returned that tells Firefox.next that there's no updates to be found here instead of that there are no updates available.

> I have no stats to go on but my guess is that the majority of users simply 
> never manually check for updates.
>
Another great reason we'd really like bug 392180 fixed :)

(In reply to comment #4)
> Incidentally do the upcoming sandbox changes make this a non-issue anyway?
>
No, the changes have already been implemented and it just involved having a checkbox instead of requiring login.
> (In reply to comment #4)
> > Incidentally do the upcoming sandbox changes make this a non-issue anyway?
> >
> No, the changes have already been implemented and it just involved having a
> checkbox instead of requiring login.

Yes, the drop of obligatory login for downloading does not change the fact that the user has to go himself to amo and look there for updates.
And if you have more than one experimental addon, this can be really annoying, and you can easily forget checking regularly, especially if you use the "update notifier"-extension, that downloads and installs (public) addons automatically.
Component: Public Pages → API
OS: Windows Vista → All
QA Contact: web-ui → api
Hardware: x86 → All
Ok let's reconsider this. I'm trying to avoid putting code into the add-ons manager that is specific to AMO or how it operates. But I think maybe we can abstract away from that a little. Perhaps we should add a case where the user sees something like "Automatic updates aren't offered for this add-on" together with a learn more link to describe why. This would allow AMO to give details on why updates aren't offered for sandboxed items. It would also allow self-hosting authors (and maybe even another case for AMO) to indicate that support for an add-on has been discontinued and there would be no further updates.
Severity: major → enhancement
Component: API → Add-ons Manager
Product: addons.mozilla.org → Toolkit
QA Contact: api → add-ons.manager
Version: unspecified → Trunk
One way or another this needs to be dealt with at some point. As wait times for review for public status go up this becomes a bigger deal. It slows down development of new extensions because users have no clue that a newer version is available to try. I currently have an experimental extension and half my users are using an old version. If the goal of many experimental extensions is to complete their "experiment" and be tested, improved, and eventually made public, then we really need to give those doing the testing at least the option to keep up and help.

If we want this to be generalized the update server would have 4 options to return: automatic update, manual update, no update, never update. AMO would not be the only place that could use this. An example would be an extension that's bundled with other software. You may not want to just update the extension automatically, because you'd want the rest the software updated with it. It could be set to check for updates and return "manual update" with a message telling the user how they can go about updating everything involved here, as Firefox wouldn't be able to update the external software itself.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [amo:want P2]
I guess this is not needed anylonger because of the new review mechanism as auto-update for prelim reviewed add-ons is enabled?

Thoughts?
The API now also returns the appropriate status of the extension, means fully reviewed vs. preliminary reviewed:

<status id="4">Fully Reviewed</status>
<status id="8">Preliminarily Reviewed</status>

So the AMO part is solved and I wonder if we can expose that information to the user, if we need to. On the other side it would only apply to extensions installed from AMO but not other websites, so not sure how helpful it would be. IMO the current behavior is perfectly fine.
All add-ons from AMO have automatic updates and a user installing a completely unreviewed add-on from AMO is much less common occurrence since it's only available through a direct link. So I think this bug is no longer needed.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.