Closed Bug 545374 Opened 15 years ago Closed 14 years ago

limit of 3Mb on size of add-on upload?

Categories

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

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 314664

People

(Reporter: stellato, Unassigned)

References

()

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.0.249.78 Safari/532.5 Build Identifier: We’re the authors of: Semantic Turkey https://addons.mozilla.org/en-US/firefox/addon/8880 We tried to upload a new version (0.7.0) of this add-on through the developer HUB at: https://addons.mozilla.org/en-US/developers/versions/add/8880 At first it tells that it is uploading the file, then… …nothing happens :-( We tried to experiment different scenarios: changed xpi file name to a short one without chars, removed the install.rdf file etc… Thought about some problem with the xpi. Locally, the xpi runs fine on different platforms (Linux, Windows and Mac) and, when we tried to use the validation service @:https://addons.mozilla.org/en-US/developers/addon/validate the behavior was the same: "uploading the file...", then nothing... We also tried to fill the extension with different files of different sizes, and it seems not related to size/name length etc… of the single embedded file (consider that we have a bit of java jars since the extension communicates with java libs) After lot of cross-checking, it seems (we are not sure though quite confident) that there is an overall upload limit of 3 megabytes on the whole size of the uploaded extension. Is it possible to extend this limit? I understand that 3Mb is an uncommon size for a Firefox extension, but it is not so “improbable” if you put java libraries inside the xpi. We experienced this problem for the first time with the new Developer’s HUB, while we always succeeded in submitting past versions (till 0.6.7 which is currently available from firefox add-ons site) which were even heavier than this one (a bit less than 6Mb) Thanks in advance for you support! Reproducible: Always Steps to Reproduce: 1. build an extension of 3Mb (fill an available extension with dumb files) 2. try to upload it (can be reproduced both by submitting an update, by submittig a new extension or by testing it) 3. if you fail to reproduce this, we can send you our specific extension Actual Results: Nothing happens on the upload site after the file has been uploaded Expected Results: I tested with smaller-than-3Mb files, and saw the result of the upload (reported error if some problems are present in the install.rdf, or continue with the upload process if everything is fine).
really sorry, I looked for "upload" keyword when looking for potential copies of this bug, and did not find 314664 before posting my one. However..yes, it seems the same problem, though they tell this could be a out-of-memory problem when running the parser, while in my case i just have to remove a java bundle jar to make it work (going down from 4.5Mb to some byte less than 3mb). Are jars decompiled by the parser? (i suppose so, since also .js files may be embedded in jars) and are (in affirmative case of the above) .class files analyzed by the parser? otherwise, it is strange that the 1.5Mb Sesame java lib caused problems to the parser. On the other side, if we reject the idea of a parser out-of-memory error, and go back to size, all recent reported problems are related to ~9Mb (or more) extensions, while my one is just 4.5Mb are you able to reply to previous questions and to suggest me some other test that i can do to really confirm if this is the same bug as 314664 or not?
The parser does unpack JARs, but we recently added a check so that it ignores .class files. This was added to AMO on February 3rd. Was your upload more recent than that?
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Yes, I packed and sent everything from 8 of february. Also, I made lot of tests, removed lot of class files from the jar in the xpi and it seems the problems is not related to size of single jars nor to the classes contained in it, but to the size of the overall xpi. The boundary seems to be exactly 3Mb. If it may be of any help, all previous versions of my extension were heavier than this and I posted them without any problem. P.S. should I move new messages about this specific discussion on <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=314664">bug 314664</a> or continue on this issue?
It appears to be the same issue, so I recommend you post a single comment with all your findings.
Ok, did some more tests and reported 'em on bug 314664. Closing here
Hi again, tried today to upload a new version of my extension: https://addons.mozilla.org/addon/semantic-turkey in this case, I upload the new version, it gets checked with no errors and a few warnings (mostly due to the presence of java classes, telling that .class is not an accepted extension, though my extension is based on the java-firefox bridge and contains classes bundled inside jars). Unfortunately, the "add version" button (sorry not sure about the exact label of the button, my one is in italian) is disabled: if I click on it nothing happens, while the "cancel" link is working correctly. The link to my extension is: http://semanticturkey.googlecode.com/files/SemanticTurkey-0.7.2-2011-01-20_b128.3.xpi
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Please don't reopen duplicate bugs.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago14 years ago
Resolution: --- → DUPLICATE
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.