Closed Bug 435102 Opened 16 years ago Closed 16 years ago

Version bumped add-on will not install

Categories

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

defect
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: baz, Assigned: fligtar)

Details

Attachments

(1 file, 3 obsolete files)

https://addons.mozilla.org/en-US/firefox/addon/6843 has been version bumped. The install.rdf says:

<em:minVersion>3.0b3</em:minVersion>
<em:maxVersion>3.0b5pre</em:maxVersion>

The AMO site has it listed with maxVersion="3.0.*"

When you attempt to install https://addons.mozilla.org/en-US/firefox/addon/6843 into Firefox 3.0 RC1, Firefox displays install confirmation dialog and after attempting to install, the message: "MitM Me 1.0 could not be installed because it is not compatible with Firefox 3.0."
This is an experimental add-on and AMO doesn't provide update.rdfs for them, so no version bumps are detected.

Possible solution: Send response with same version number (prevents updates).
Indeed, here is the log from using Firefox 3 RC1 and enabling extension logging:

*** Phone Home Listener: Update Started
*** Datasource: Update Started
*** Phone Home Listener: Update For mitmme@johnathan.nightingale started
*** Datasource: Addon Update Started: mitmme@johnathan.nightingale
*** RDFItemUpdater:checkForUpdates sending a request to server for: https://versioncheck.addons.mozilla.org/update/VersionCheck.php?reqVersion=1&id=mitmme@johnathan.nightingale&version=1.0&maxAppVersion=3.0b5pre&status=userEnabled,incompatible&appID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=3.0&appOS=Darwin&appABI=x86-gcc3&locale=en-US, item = ({id:"mitmme@johnathan.nightingale", version:"1.0", installLocationKey:"app-profile", minAppVersion:"3.0b3", maxAppVersion:"3.0b5pre", name:"MitM Me", xpiURL:"file:///Users/Basil/Library/Caches/TemporaryItems/tmp.xpi", xpiHash:"", iconURL:"", updateRDF:"", updateKey:"", type:2, targetAppID:"{ec8030f7-c20a-464f-9b0e-13a3a9e97384}"})
*** RDFItemUpdater:onDatasourceLoaded: Datasource empty.
If you are an Extension developer and were expecting there to be
updates, this could mean any number of things, since the RDF system
doesn't give up much in the way of information when the load fails.

Try checking that: 
 1. Your remote RDF file exists at the location.
 2. Your RDF file is valid XML (starts with <?xml version="1.0"?>
    and loads in Firefox displaying pretty printed like other XML documents
 3. Your server is sending the data in the correct MIME
    type (text/xml)
*** RDFItemUpdater:_parseV20UpdateInfo: No updates were found for:
mitmme@johnathan.nightingale
If you are an Extension developer and were expecting there to be
updates, this could mean any number of things, since the RDF system
doesn't give up much in the way of information when the load fails.

Try checking that: 
 1. Your RDF File is correct - e.g. check that there is a top level
    RDF Resource with a URI urn:mozilla:extension:{GUID}, and that
    the <em:updates> listed all have matching GUIDs.
*** Phone Home Listener: Update For mitmme@johnathan.nightingale ended, status = 8
*** Version Check Phone Home Completed
 
Target Milestone: --- → 3.4.3
Summary: Version bumped add-on will not install → Version bumped add-on will not install / version bumps should be applied to install.rdfs of hosted xpis
Without updated install.rdf the user always needs internet connection to (re)install extension or rebuild extensions.rdf
Also updating install.rdf would make it easier to install version-bumped experimental add-ons or add-ons for TB3
Assignee: nobody → fligtar
For sandbox add-ons, we'll return the same version's information with any potential compatibility bumps. If this severely impacts performance, we'll instead disable compatibility changes for sandboxed add-ons.

We have decided on multiple occasions that we won't rewrite install.rdfs for this purpose.
Summary: Version bumped add-on will not install / version bumps should be applied to install.rdfs of hosted xpis → Version bumped add-on will not install
Justin, looks like bug 436102 is related to this as well. (It's a public add-on)
Attached patch patch, v1 (obsolete) — Splinter Review
Adds a query that determines if the add-on is hosted on AMO and what its status is. If the add-on is hosted and public, it runs the same query as before. If the add-on isn't public, it will only return information for the version the user pinged with to obtain updated compatibility information.
Attachment #323180 - Flags: review?(morgamic)
Will this patch help for bug 436102 too? It's a public extension, so if the query doesn't change in that case, I guess the answer is no
Comment on attachment 323180 [details] [diff] [review]
patch, v1

Before patch:
Requests per second:    183.94 [#/sec] (mean)
Time per request:       27.182 [ms] (mean)
Time per request:       5.436 [ms] (mean, across all concurrent requests)

After patch:
Requests per second:    2.33 [#/sec] (mean)
Time per request:       2146.896 [ms] (mean)
Time per request:       429.379 [ms] (mean, across all concurrent requests)

Test:
ab -n 50 -c 5 "http://morgamic.khan.mozilla.org/amo/site/services/update.php?reqVersion=1&id={8620c15f-30dc-4dba-a131-7c5d20cf4a29}&version=1.3&maxAppVersion=3.0b5pre&status=userEnabled&appID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=3.0b5pre&appOS=Darwin&appABI=x86-gcc3&locale=en-US"
Comment on attachment 323180 [details] [diff] [review]
patch, v1

Seems to take a massive perf hit for non-sandbox add-ons.  Maybe something with using guid and inactive in the same WHERE clause?
Attachment #323180 - Flags: review?(morgamic) → review-
Attached patch patch, v2 (obsolete) — Splinter Review
This patch fixes an error in the previous that was returning the wrong add-on ID and type. It's still extremely slow (2.33 req/s), so not requesting review.

I can try to optimize the patch back down to 1 larger query, or we can just go with option B which is disabling targetapp modifications for sandbox add-ons or putting a warning that the changes won't affect updating users.
Attachment #323180 - Attachment is obsolete: true
Attached patch patch, v3 (obsolete) — Splinter Review
This fixes the bottleneck that was in the main query and my ab testing shows it as actually faster than the before the patch now.
Attachment #323504 - Attachment is obsolete: true
Attachment #323578 - Flags: review?(morgamic)
Comment on attachment 323578 [details] [diff] [review]
patch, v3

This looks good to me, but I'd like some tests in tests/services/update.test.php to cover this since it's a core service.

So create a testVersionInformationForSandboxAddon() method to test the expected behavior.  There is a sandbox addon in the test db already that you can use for this.
Attachment #323578 - Flags: review?(morgamic) → review-
Target Milestone: 3.4.3 → 3.4.4
Target Milestone: 3.4.4 → 3.4.5
This bug is quite important, as many add-ons have been bumped using developpers panel and people are complaining that some add-ons specified as "compatible with: Firefox 3.0 - 3.0.*" can not install (as maxversion in install.rdf is still 3.0b* or 3.0pre).

For example IE Tab: https://addons.mozilla.org/fr/firefox/addon/1419
Sorry, I hadn't noticed that Firefox looks for compatibility info in the update.rdf.
Same patch with a test.
Attachment #323578 - Attachment is obsolete: true
Attachment #327899 - Flags: review?(morgamic)
Comment on attachment 327899 [details] [diff] [review]
patch, v3 with tests

Thanks for writing the tests.  This looks okay to me.
Attachment #327899 - Flags: review?(morgamic) → review+
Thanks. Going to check in, assuming we still want to take this for 3.4.5.
r16793
Status: NEW → RESOLVED
Closed: 16 years ago
Keywords: push-needed
Resolution: --- → FIXED
3.4.5 was pushed on Friday.
Keywords: push-needed
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: