299377 - Avoid "Not a valid install package" errors by delaying availability

Status: RESOLVED DUPLICATE of bug 254632

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

Description

[Ben Basson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050701 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050701 Firefox/1.0+

Once an extension has been approved, it appears that it shows up on UMO soon
after. In my opinion there needs to be a larger gap before the new version
appears on the update system and website to allow all of the mirrors to synchronise.

I'm sure this is the cause of the seemingly random "Not a valid install package"
errors that I've had reported after my latest version of Disable Targets For
Downloads was approved. The XPI obviously works fine, otherwise it wouldn't have
been given approval.

Reproducible: Didn't try

Steps to Reproduce:

Comment 1

[benspace]

I can reproduce this bug. It happened for a week or two when I released my first
extension, MyspaceBar. Gradually the percentage of "Not a valid install package"
errors decreases, but the whole time, users believe the extension developer
submitted an invalid xpi.

An alternate solution would be to maintain a list of mirrors that have mirrored
the file, similar to how other download sites do it. Then ensure that users are
only redirected to servers where the files that actually exist.

Related bug?: bug 291357

Also, Firefox should handle the case of a 404 error or whatever the mirrors
return, instead of giving the error message that it is an invalid xpi.

Comment 2

[Chris Blore]

I know this is certainly planned/in the process of being implemented at the moment.

->NEW so everybody knows this and to avoid further duplication

Comment 3

[Chris Blore]

*** Bug 284567 has been marked as a duplicate of this bug. ***

Comment 4

[Michael Morgan [:morgamic]]

The general idea behind this is covered in bug 314019.

*** This bug has been marked as a duplicate of 314019 ***

Comment 5

[Cameron]

*** This bug has been marked as a duplicate of 254632 ***