Closed
Bug 1173852
Opened 10 years ago
Closed 10 years ago
Beta release fails validation, not clear why, so can't fix, so can't do my beta release
Categories
(addons.mozilla.org Graveyard :: Add-on Validation, defect)
addons.mozilla.org Graveyard
Add-on Validation
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 1172035
People
(Reporter: 52qtuqm9, Unassigned)
Details
Attachments
(1 file)
150.40 KB,
application/x-xpinstall
|
Details |
Validation of the attached XPI is failing with: "Your version was detected as beta. It didn't pass automatic validation and thus can't be submitted. If you didn't mean to submit it as beta, please uncheck the beta channel option."
The validation is reporting 25 messages, none of which are new, all of which have been reviewed in the past by AMO editors and ruled harmless.
I hope / assume that only _some_ of the 25 messages are the ones that are causing the release to fail automatic validation, but I have absolutely no way of knowing from the full validation report which ones I actually have to fix to pass automatic validation.
Some of the 25 messages are due to deficiencies in the add-on validator, i.e., they are false positives, so I _can't_ fix them. Some of them are even in third-party libraries bundled with my add-on.
I need to get this release out. Please help.
Reporter | ||
Updated•10 years ago
|
Status: NEW → UNCONFIRMED
Ever confirmed: false
Reporter | ||
Comment 1•10 years ago
|
||
One of the complaints I am getting is this:
>on* attribute being set using setAttribute
>Signing severity: medium
>Warning: To prevent vulnerabilities, event handlers (like 'onclick' and 'onhover') should always be defined using addEventListener.
>chrome/content/prompt.js
>120 // http://stackoverflow.com/questions/16779316/how-to-set-an-xul-key-dynamically-and-securely
>121 key.setAttribute("oncommand", "//");
>122 key.addEventListener("command", cmd, false);
However, as the answer to the referenced StackOverflow question indicates, I _must_ set the "oncommand" attribute on this key, or the key event is never fired. I'm not just taking the answer's word about this -- I _saw_ this behavior before I added the setAttribute call to my add-on. So the add-on validator is complaining about something I _must_ do in order for my add-on to work properly.
Reporter | ||
Comment 2•10 years ago
|
||
Well, I take back part of this bug report. I was able to figure out, even though this isn't documented or noted anywhere in the UI, that the messages that were causing automatic validation to valid are the ones marked with "Signing severity". So I managed to come up with workarounds for those (including a workaround for the error in comment 1), and now my add-on is passing automatic validation.
So I guess I still think this bug has a remaining issue that needs to be addressed, and that is that the UI needs to make it crystal clear which messages are causing automatic validation to fail. I don't think just putting the "Signing severity" line in those messages is sufficient, since it is vague and undocumented.
Comment 3•10 years ago
|
||
I'm glad you managed to fix this on your own. You're running into bug 1172035 and bug 1172030, both of which we'll try to fix very soon. Calling this a dupe.
Status: UNCONFIRMED → RESOLVED
Closed: 10 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
•