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)
addons.mozilla.org Graveyard
Developer Pages
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).
Comment 1•15 years ago
|
||
Dupe of bug 314664?
Reporter | ||
Comment 2•15 years ago
|
||
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?
Comment 3•15 years ago
|
||
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
Reporter | ||
Comment 4•15 years ago
|
||
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?
Comment 5•15 years ago
|
||
It appears to be the same issue, so I recommend you post a single comment with all your findings.
Reporter | ||
Comment 6•15 years ago
|
||
Ok, did some more tests and reported 'em on bug 314664. Closing here
Reporter | ||
Comment 7•14 years ago
|
||
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 → ---
Comment 8•14 years ago
|
||
Please don't reopen duplicate bugs.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago → 14 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Updated•9 years ago
|
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•