Closed Bug 462108 Opened 13 years ago Closed 13 years ago

Bandwagon/interactive collections add-on files on preview are corrupt/-260 error

Categories

(addons.mozilla.org Graveyard :: Collections, defect)

defect
Not set
blocker

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: stephend, Assigned: wenzel)

References

()

Details

Assigning "blocker" severity because this is really stopping me from testing.

Steps to Reproduce:

1. Install Firefox 3.0.3 (of course, you should already have it :-P)
2. Load https://preview.addons.mozilla.org/en-US/firefox/collections/interactive
3. Add all of the add-ons to your "shopping cart" and try to install them

Expected Results:

All add-ons install

Actual Results:

I'll let this bug address the following error:

"Firefox could not install the file at 

https://preview.addons.mozilla.org/en-US/firefox/downloads/file/28718/firefox_companion_for_ebay-1.6-fx-linux.xpi

because: Signing could not be verified.
-260"

however, there also are numerous "...not compatible with Firefox 3.0.3" errors, which I don't understand.

I hope this helps:

https://preview.addons.mozilla.org/en-US/firefox/downloads/file/27852/fast_video_download-1.6-fx.xpi

GET /en-US/firefox/downloads/file/27852/fast_video_download-1.6-fx.xpi HTTP/1.1
Host: preview.addons.mozilla.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: __utmz=164683759.1225228664.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none); __utma=164683759.149501363.1225228664.1225261743.1225265608.5; __utmc=164683759; __utmb=164683759

HTTP/1.x 302 Found
Date: Wed, 29 Oct 2008 07:33:57 GMT
Expires: Wed, 29 Oct 2008 08:33:57 GMT
Cache-Control: max-age=3600      ,public
Connection: Keep-Alive
Via: NS-CACHE-6.0:   4
Server: Apache/2.2.3 (Red Hat)
X-Powered-By: PHP/5.1.6
X-AMO-ServedBy: mrapp520.mozilla.org
Last-Modified: Wed, 29 Oct 2008 07:33:57 GMT
Location: http://releases.mozilla.org/pub/mozilla.org/addons/3590/fast_video_download-1.6-fx.xpi
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Why are we setting the content-type for an XPI as text/html, and at 0 bytes?
(I should've read the HTTP spec before spewing that the content-type header is in bytes; it's in octets.  Sorry for the double spam.)
I assume a redirect is 0 bytes-uhm-octets long (FYI, bytes and octets are usually the same, but "octet" is more precise as it stresses the fact that exactly 8 bits are meant).

I also can't reproduce this quite yet, probably because I didn't check *all* add-ons for installation. The amount checked seems to be relevant. Maybe we need to limit it?
Maybe we can make a suggestion up-front to the user about how many we suggest to add and then put a note saying that they can always come back and add more later.

Is there a particular inflection point where things start to fail?  Or is it completely random?  We could take a look at the average xpi file size and suggest that a total bundle size of XMB should be the download limit (based on a certain, common connection speed).
Interesting; a datapoint: when I try to install https://preview.addons.mozilla.org/en-US/firefox/downloads/file/15261/linkedin_companion_for_firefox-3.0.1-fx.xpi directly, I get "LinkedIn Companion for Firefox 3.0.1 could not be installed because it is not compatible with Firefox 3.0.3."

However, when I install it with a bunch of the others, its error message changes to the -260 error, as above.  Perhaps the multiple "not compatible with Firefox 3.0.3" errors are causing/exacerbating the -260 error(s)?
I think the LinkedIn xpi isn't linking to the right place.  From the AMO page it is linking to 3.1.2-fx.xpi as follows:

https://addons.mozilla.org/en-US/firefox/downloads/file/34770/linkedin_companion_for_firefox-3.1.2-fx.xpi
I don't think most of the files are; Jeremy, could you take a look?
Does this work for add-ons with the correct URLs?  If it does, I suggest this:
* push interactive collections code tonight
* test over the next week in prod (it will be behind login)
* fix any persisting errors before the final launch nov 18
Hi Jeremy -- can you take a look at this please?  We need to get this sorted really soon so we can make launch.
(In reply to comment #8)
> Does this work for add-ons with the correct URLs?  If it does, I suggest this:
> * push interactive collections code tonight
> * test over the next week in prod (it will be behind login)
> * fix any persisting errors before the final launch nov 18
OK; all add-ons install now on prod except for:

Cooliris 1.8.5.14751
Foxmarks 2.5.3
Delicious 2.0.104
Firefox Companion for eBay 1.6.6
Digg Toolbar 1.0.2

(All of the above fail to install with -260 errors.)

Fred tells me that it's probably the platform detecting we need to do, that would fix this.
Actually, I just checked on Digg Toolbar, and they do not serve a different file for different platforms. So more browser sniffing won't fix the problem with this add-on.
Maybe we are accidentally trying to serve yet-experimental updates? I noticed Digg has one in the queue (1.0.3, that is). Will look.
Kev - do you have any insight as to why eBay Companion won't install as part of a bundle here (see comment #11)?
I just committed r19563, sniffing the user's platform with JavaScript, in order to install the right file. Stephen, will you try out if that solves your problem?
Of course I forgot to change the hash according to the platform, as Stephen pointed out. Fixed in r19566. Sorry 'bout that.
I'm hoping comment 16 fixes my -260 errors once it gets pushed to production; right now, I see that error on both prod and preview.
David's given us permission to remove the Digg Toolbar extension, as it's definitely causing issues with other add-ons; I'd prefer, of course, to figure out what the real problem is (since, by itself, it can be installed just fine), but we're running out of time.
So, it's not just the Digg Toolbar, and I think we should be careful to test the other problematic combinations.

For instance, if you install Foxmarks and the Delicious Bookmarks extensions together, Delicious fails to install (this is on production, not preview.AMO).

mossop: any reason why we're getting -260 errors installing those two together, or the Digg Toolbar with Foxmarks, when by itself, each installs just fine?
Update:

Thanks to mossop for figuring out that the problem is likely that the problematic add-ons are signed, which causes us to trigger bug 453545; there's no way we can get a client-side fix in time for this push, so Fred will likely have to work around it in some fashion.  Sorry for not roping mossop in earlier, as we couldn't started the work to mitigate around this issue then.
s/couldn't/could've, sigh.
Depends on: 453545
OS: Windows XP → All
Hardware: PC → All
CCing fligtar as this directly affects Bandwagon/collections.
If we have to surface some sort of warning, we should make it as friendly as possible and put it up top.  

To confirm, this only happens when any 2 of the add-ons that are signed are installed, correct?

I talked with j-slater, and language should be something like the following:

"Oops!  Unfortunately this unique combination of add-ons doesn't play well together.  Instead, you'll have to download the add-ons below one at a time.  We're working on a fix, but in the meantime we apologize for the inconvenience."

Boriss -- can you weigh in with UX thoughts?
Re IRC discussions, Mossop believes that we can get around this by calling the install confirmation dialog twice or possibly more by installing multiple items separately.  So, what the user sees is a confirmation page for their signed icons, presses "Install Now" and then gets a list of the signed ones.  This is being tested, but clearly the goal is to show as few confirmation pages as humanly possible.

Potential problem is that the add-ons manager will appear after the first confirmation is dismissed and display progress bars for all installs.  The second installtrigger dialog should appear after the first, but may appear while the install of the first items is still going.
Just some clarifications:

(In reply to comment #24)
> Re IRC discussions, Mossop believes that we can get around this by calling the
> install confirmation dialog twice or possibly more by installing multiple items
> separately.  So, what the user sees is a confirmation page for their signed
> icons, presses "Install Now" and then gets a list of the signed ones.  This is
> being tested, but clearly the goal is to show as few confirmation pages as
> humanly possible.

The user would see a confirmation for the unsigned add-ons, followed by multiple confirmations (one for each signed add-on). At least that assumes what I suggested on IRC. So long as only one signed add-on appears in any of the install confirmations then you will avoid the bug.

> Potential problem is that the add-ons manager will appear after the first
> confirmation is dismissed and display progress bars for all installs.  The
> second installtrigger dialog should appear after the first, but may appear
> while the install of the first items is still going.

The add-ons manager will appear after the first confirmation and initially display progress bars for the add-ons listed in that first confirmation. As you user accepts more confirmations more progress bars should appear in the add-ons manager.
This is implemented and checked into trunk as r19775.

Some notes:
- the 6 add-on IDs in question are hard-coded. So it's still important that the bug is fixed, which of course is on the way. Then this hack needs to go.
- The first signed add-on is installed with the unsigned batch, all others are triggered separately. That keeps the chance of more than one install dialog as small as possible.
- The behavior is exactly as described by Mossop. The add-on manager already starts working in the background while the additional install dialog(s) pop(s) up. Note that the "success!" dialog is already triggered as well, bearing all add-on's names, even if you haven't clicked "install" on the signed add-on's dialog yet.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → 4.0.3
Assignee: nobody → fwenzel
Both:

* foxkeh_theme-1.0-fx.jar
* wizz_rss_news_reader_-3.0.0.0-fx.xpi

are returning -260 (though in separate installTrigger popup dialogs); doesn't that mean those are signed, and need to be added to the exception list, Fred?

(This was tested on preview.AMO, with the user-created pref of |extensions.checkCompatibility| set to |false| in about:config.)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
If those two are indeed signed (and thus another set of "problem" add-ons), I'd strongly consider taking both of those out (especially foxkeh).  We'd probably want to replace Wizz with another news reader though.
Neither of these add-ons is signed. Neither of them is actually installable even regularly (through the website) on preview for me, are they for you? I mark this dependent on the preview update (bug 464829).
Depends on: 464829
By my calculations, by taking out Digg as one of the signed (aka "problem") add-ons, (reducing the number from 5 to 4), we reduce the odds of a user picking a problem combo from 81%, to 68%.

That, plus the fact that digg has a popup experience on first-run make it a good call to remove.
I think (and hope) this is fixed. Haven't seen any problems installing lately. Reopen if the problem persists.
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
Target Milestone: 4.0.3 → 4.0.4
Verified FIXED for me, too; I've installed this full set of add-ons, as well as random ones, multiple times, with no issues (even without the app-compatibility-override check I mentioned in comment 27.
Status: RESOLVED → VERIFIED
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.