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)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1172035

People

(Reporter: 52qtuqm9, Unassigned)

Details

Attachments

(1 file)

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.
Status: NEW → UNCONFIRMED
Ever confirmed: false
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.
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.
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
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: