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)
addons.mozilla.org Graveyard
Public Pages
Tracking
(Not tracked)
RESOLVED
WORKSFORME
6.1.6
People
(Reporter: vish_moz, Unassigned)
References
()
Details
Attachments
(3 files)
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
Reporter | ||
Comment 1•14 years ago
|
||
Updated•14 years ago
|
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
Comment 4•13 years ago
|
||
(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.
Updated•13 years ago
|
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Comment 6•13 years ago
|
||
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 → ---
Comment 7•13 years ago
|
||
Comment 8•13 years ago
|
||
(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.
Comment 9•13 years ago
|
||
What do you guys want to do with this?
Whiteboard: [ddn]
Target Milestone: Q1 2011 → 4.x (triaged)
Comment 10•13 years ago
|
||
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]
Comment 11•13 years ago
|
||
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.
Comment 13•13 years ago
|
||
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
Comment 14•13 years ago
|
||
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
Comment 15•13 years ago
|
||
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.
Comment 16•13 years ago
|
||
(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.
Comment 17•13 years ago
|
||
(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 :(
Updated•13 years ago
|
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Updated•8 years ago
|
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•