Created attachment 8348586 [details] linkificator1.6.0.xpi User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release) Build ID: 20131209204824 Steps to reproduce: 1. click on "Upload a New Version" from my add-on page "Version History" 2. Select "All Platforms" 3. Select my xpi (see attachment) Actual results: An error is displayed: Your add-on failed validation with 1 error * Invalid file name in archive: / But when I click on "See full validation report", I have no error (only warnings). Expected results: Validation step should be successful. Nota: building same xpi with SDK 1.14 can be successfully uploaded.
This seems to be an error on the AMO side rather than the validator, since the standalone validation tool doesn't show the error. How did you create the extension package?
I used tool 'cfx xpi' from SDK 1.15 to create my xpi file.
Adding some SDK people to look into the packaging problem. However, this is still a bug on the AMO code that checks the add-on *before* validation.
I did a couple of things: 1. downloaded the attached xpi and used the validator to validate it, this worked as expected. 2. took a different add-on project I have, packaged it with 1.15, then validated it with the validator. This also worked fine. I don't think the packaging is the issue. FYI I used the validator here: https://addons.mozilla.org/en-US/developers/addon/validate
Try (2), but instead of only validating it, try uploading it to the staging server. The problem seems to happen with an AMO pre-validation that is separate from the validator.
By uploading I mean to actually submit it as a new add-on, instead of using the /validate page.
(In reply to Jorge Villalobos [:jorgev] from comment #6) > By uploading I mean to actually submit it as a new add-on, instead of using > the /validate page. The this is completely an AMO bug, and not an SDK bug right?
Looks like an AMO bug, yes.
Workaround for this bug: 1. Open up the xpi as an archive 2. Remove the empty directory inside that has the same name as the folder where cfx xpi was ran This worked for me, and after these steps the add-on still works properly.
Thanks for the workaround. In my case, I have am empty directory with name '/'. Removing this empty directory solves the problem. So, clearly, the problem is NOT on AMO side, but on cfx tool side. The tool generates a wrong xpi file.
(In reply to Marc Chevrier from comment #10) > Thanks for the workaround. In my case, I have am empty directory with name > '/'. Removing this empty directory solves the problem. > > So, clearly, the problem is NOT on AMO side, but on cfx tool side. The tool > generates a wrong xpi file. I don't necessarily see it that way. Has anything changed in cfx? Not lately ( until we release 1.16 ). Bu every time I release the SDK I make sure the validator works with it, so it does not seem like most users will run into this to me. I guess I want two answers: - when did cfx start adding empty directories, and under what conditions? - when did the validator start caring about empty directories?
- cfx starts to generate erroneous xpi with version 1.15 (1.14 is OK). No special condition. Same sources used with 1.14 (even with option --strip-sdk) generates a correct xpi. - validator starts to reject xpi when I starts to use 1.15 to package my add-on.
This problem still appears to be present in addon-sdk-1.17. I worked around it with `zip -d *.xpi "\/"`
Created attachment 8526797 [details] addonsdk This patch is equal to this pull-request: https://github.com/mozilla/addon-sdk/pull/1731
Comment on attachment 8526797 [details] addonsdk I'm not a reviewer for the addon-sdk. I'd suggest email@example.com
any news with this patch? If firstname.lastname@example.org is busy, any other reviewer?
Comment on attachment 8526797 [details] addonsdk I'm sorry, we are not going to release any new versions of cfx, our future plan is to uplift most functionality to firefox itself & expose cli interface via nodejs (this project lives under https://github.com/mozilla/jpm) Given that no official release will be made for CFX any more I do not think there is much point in me reviewing this patch.