User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.5) Gecko/2008121622 Ubuntu/8.04 (hardy) Firefox/3.0.5 Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.5) Gecko/2008121622 Ubuntu/8.04 (hardy) Firefox/3.0.5 I was attempting to "Submit New Add-on" to AMO. I went through the wizard, providing license info, and then platforms ( Linux, MacOSX, Windows) and selecting the XPI file. I then click the "Upload File" button and wait indefinitley. The status bar says "Sending request to addons.mozilla.org..." and the web page has a little blue spinner with "Uploading file..." - after about half an hour, the spinner and Uploading file text disappear. I have tried this six times. I have also contacted irc.mozilla.org#amo and tried some suggestions from there. Reproducible: Always Steps to Reproduce: 1.Start "Submit New Add-on" Wizard 2.Provide license 3.Upload a large XPI file ( try to ) Actual Results: after about half an hour, the spinner and Uploading file text disappear - progress rose ends. Expected Results: New addon submission Looks like the file is larger than the scripts can handle. I would appreciate any alternate means of upload, avoiding the wizard - e.g. FTP. Thank You.

You are probably hitting PHP's file upload limit. I agree that we should make it visible what that limit is. However, I think that 19.1 MB is excessively large, even for multiple platforms. A workaround is to break the extension down for 1 for each platform you do support.

I will attempt to work around this bug with the addon web site by splitting my xpi file. It currently supports seven platforms, with native binary plugins for each. However, I forsee that this will then cause problems later on with having to have seperate update.rdf files for different platforms. Isn't one of xpi's strengths that it is cross-platform? If anyone happens to know the file size ceiling on https://addons.mozilla.org/en-US/developers/addon/submit then please let me know

The underlying issue here (upload limits as well as other upload possibilities) are both dupes of other bugs (feel free to search). CCing fligtar though to help the OP for now, and for consideration on when and how to fix the upload limits.

You have multi-megabyte binaries for each platform? It seems like you should really split those up for the sake of your users' install experience, and update experience, and well, lots of things. 19 MB is bigger than Firefox itself on any platform... Is the xpi at least created with zip -9?

I am now re-trying the experiment with an 11.4 MB XPI File. The smaller file is getting me further ( I now get feedback about how much it likes my install.rdf file :-) ) So I can report that the breaking point is somewhere larger than 11.4 MB, but smaller than 19.1 MB. I would like to suggest that this be stated on the "Submit new Add-On" Wizard page until a better fix be found. The initial file supported these platforms: <em:targetPlatform>WINNT_x86-msvc</em:targetPlatform> <em:targetPlatform>Linux_x86_64-gcc3</em:targetPlatform> <em:targetPlatform>Linux_x86-gcc3</em:targetPlatform> <em:targetPlatform>Darwin_ppc-gcc3</em:targetPlatform> <em:targetPlatform>Darwin_x86-gcc3</em:targetPlatform> <em:targetPlatform>WINNT_x86_64-msvc</em:targetPlatform> <em:targetPlatform>Darwin_Universal-gcc3</em:targetPlatform> The new smaller file supports just the first five. If anyone knows of a definitive list of the platforms that Firefox supports, I would be grateful for a link. I have been unable to find such a list. I now have two versions of my xpi install package - a smaller and less functional one for AMO, and a complete and more general one available from my own website. I wonder if this is the intent of the AMO maintainers? Or simply an unfortunate side-effect of mistakes made in the amo website design. I should point out to Mike that Firefox itself does not use the XPI format for install - it has a separate installer for each platform. If it did it would be much larger. The idea is that although Firefox has to deal with platform specificity, it can then shield add-on developers from also having to do so. And yes, of course I use zip -9. Any comments regarding inherent problems with the XPI specification should be directed to the maintainers of that specification, over at: https://developer.mozilla.org/en/Bundles It seems to me that the consensus here is that the cross-platform nature of an XPI file is only meant for small files, and that it is better for everyone to have a single xpi file for each platform supported, in most cases. It means that the end-user does not have to download and store unnecessary code - so making for a faster and more efficient install. This xpi platform splitting then breaks the update.rdf mechanism, but that does not matter because AMO does not use it ( and in fact dis-allows updateURL, updateKey, etc. ). We can hope that in future the XPI install.rdf specification will be generalized to allow referential platform specific files - thus keeping it's platform neutral nature, and yet not imposing a bandwidth overhead on the users.

I don't get why you're shipping x86, ppc, and UB version on Mac. The universal binary should work for both x86 and PPC. (that is, in fact, what a universal binary is supposed to do.) The 64-bit version on Windows isn't something we produce, so there is a very small likelihood that users would use it. My point wasn't meant to be directly comparative, but to point out that it seems strange to ask users to download an add-on that is larger than the app itself, and probably not the ideal user experince. Yes, XPI is meant to be cross-platform, and allow for shipping a single package across multiple platforms. For example, Weave supports seven binary platforms in a single package (not the same set), but the individual binaries are small and the total XPI size remains less than 1 MB. However, a little bit of common sense should ideally come into play when distributing very large packages. Having an extra half-megabyte isn't a big deal, but having an extra 16 MB is. That said, I think you probably want to ship Windows, Linux, Darwin UB, and Linux x86-64. That should be the smallest set of binaries to build and maintain, and will at least cover all officially-supported platforms that Mozilla ships.

Mike: I tried your idea about only shipping a universal binary. Turns out it doesn't work. The latest Mac OS X Firefox (v3.5.1) gives an "Incompatible extension" error, and requires either ppc or x86, whichever is native.

Splitting the xpi file hits another bug, this time in "Add New File" to "Versions and Files". In adding platform-specific xpi files, you cannot add a Linux 32-bit and then a Linux 64-bit xpi file, as there is only "Linux" as a platform option. However Firefox most certainly has 32-bit and 64-bit versions on Linux.

That's definitely a bug we need to fix. Can you file that separately and CC me? As for the universal binary... what if you put the dylib into just platform/Darwin ? I don't think we recognize that value for the XPCOM ABI, where did you find it? (Weave puts our universal binary into Darwin, as there's no documented XPCOM ABI value for universal binaries)

Duping, re: comment 3.