Closed Bug 610041 Opened 14 years ago Closed 13 years ago

If compatibility range specified in /versions page is not the same as install.rdf, add-on install fails

Categories

(addons.mozilla.org Graveyard :: Public Pages, defect, P4)

defect

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: vish_moz, Unassigned)

References

()

Details

Attachments

(3 files)

Attached image addon details page
Setup: Use Firefox beta 5

STR:
1. on Fx b5 go to the 'Download Statusbar' add-on page, https://addons-next.allizom.org/en-US/firefox/addon/26/
2. Note: On the add-on details page it says , this add-on works with: Firefox 3.0 - 4.0b6pre
3. click 'Add to Firefox'

Actual result:
you get error message while installing, "This addon is not compatible with Firefox
b5"

Expected result:
Since the install.rdf says that the add-on is compatible only up to Firefox b5pre
but the UI on developer manager pages says its compatible up to Firefox b6pre then either of the following should be implemented:
1. The developer should not be able to change the compatibility values on the 'Edit Versions & Files' page
2. The 'Works with' field on the add-on details page should go with what's in the install.rdf
Attached image install file
Depends on: 599043
Summary: unable to download add-on compatible up to Fx 4.0b6pre on Fx 4b5 → If compatibility range specified in /versions page is not the same as install.rdf, add-on install fails
This still happens.
Target Milestone: --- → 6.0.0
I thought the site overrode install.rdf.
Target Milestone: 6.0.0 → Q1 2011
(In reply to comment #3)
> I thought the site overrode install.rdf.

It does (though only for the latest version of the add-on since that is all AMO includes in its update.rdf).

I just tried the STR in comment 0 and it installed fine for me on a current nightly.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
I can still reproduce this:

Try installing 2.9.10 from https://addons.mozilla.org/en-US/firefox/addon/twitterbar/versions/
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Attached image screenshot
(In reply to comment #6)
> I can still reproduce this:
> 
> Try installing 2.9.10 from
> https://addons.mozilla.org/en-US/firefox/addon/twitterbar/versions/

2.9.10 isn't the newest version of Twitterbar that is compatible with your version of Firefox so AMO won't give compatibility updates for it.
What do you guys want to do with this?
Whiteboard: [ddn]
Target Milestone: Q1 2011 → 4.x (triaged)
When Firefox does a compatibility check we should only return information about that version, not the latest version. We'll need to read the updateType to determine which pings are updates and which are compatibility checks.

From https://bugzilla.mozilla.org/show_bug.cgi?id=392180#c14 it looks like we want codes 49 and 35 to have this behavior.

This is really low priority though.
Priority: -- → P4
Whiteboard: [ddn]
That would work. If you didn't want to care about the updateType you could make the update service always return information about theversion requested and the newest version compatible with their app.
So, basically we want to change the update script to be:

> if updateType in [35,49]:
>     # Look at the version in the GET URL and return 
>     # that compatibility information
> else:
>     # Find the latest version of the add-on and return 
>     # that compatibility information
STR:
1. Using firefox 5, try to install live http headers. (https://addons.mozilla.org/en-US/firefox/addon/live-http-headers/)
2. Check the compatibility version range in the install.rdf


observed behavior:
Install fails on Firefox 5 since the max supported version in the install.rdf is 4.0.* whereas the detail page claims that the add-on is supported up to 6.* 



<em:targetApplication>
<Description>
<em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id><em:minVersion>0.8</em:minVersion>
<em:maxVersion>4.0.*</em:maxVersion>
</Description>
Target Milestone: 4.x (triaged) → 6.1.6
Did Firefox 5 check the site to see if it was compatible?  That check is a fundamental flow in how we handle updates - if it's broken not only is it a different bug than this, but it's critical to fix asap.
(In reply to comment #15)
> Did Firefox 5 check the site to see if it was compatible?  That check is a
> fundamental flow in how we handle updates - if it's broken not only is it a
> different bug than this, but it's critical to fix asap.

Updating an older version works fine. The problem is while installing the add-on afresh.
(In reply to comment #14)
> STR:
> 1. Using firefox 5, try to install live http headers.
> (https://addons.mozilla.org/en-US/firefox/addon/live-http-headers/)
> 2. Check the compatibility version range in the install.rdf
> 
> 
> observed behavior:
> Install fails on Firefox 5 since the max supported version in the
> install.rdf is 4.0.* whereas the detail page claims that the add-on is
> supported up to 6.* 
> 
> 
> 
> <em:targetApplication>
> <Description>
> <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id><em:minVersion>0.8</em:
> minVersion>
> <em:maxVersion>4.0.*</em:maxVersion>
> </Description>

I cannot reproduce this issue anymore :(
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → WORKSFORME
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: