Unrealistic demands / bad feedback from add-on review

I had to let my add-on to be manually reviewed because, according to automagic validation, the libraries i used had

Access to the Function global
Markup should not be passed to innerHTML dynamically.

Your add-on, UpoOpu for FireFox (lite) 1.2.15, didn’t pass review and therefore won’t be signed.

Well, that can happen right, so i submit for manual review, after all, my add-on is simple, i re-use 90% of the code for the chrome version of it, and that one happily sits in the chrome store. But to my surprise i get the following reply

Comments:
Your version was rejected because of the following problems:

  1. Please include each third party library in a separate file and make sure it is bit-identical to the original hosted on the maintainer’s website.

Please fix them and submit again. Thank you.

This is impossible, a quick count shows i’m using roughly 20 javascript libs (jquery, more than a few jquery addons, mootools plus some addons, underscore, none of them the most recent (the last time i updated jquery things in ff broke, so i’ll never update a js lib again). Now i’m asked to track down the exact (old) bit-identical version of said libs that might or might not be hosted anymore. Moreover some libs (jquery and mootools notably), have some local fixes to make them work in my add-on, there is no identical version anywhere.

I’m sorry to say, but this whole signing process seems not well thought out. It feels i’m stonewalled from getting my add-on signed, leaving me no other choice than to basically explain my users how to install pale-moon/water-fox or chrome.

Keep in mind, my add-on has been made to help people, it’s a spare time project, i don’t have the spare time to comply with the demands. A positive estimate is that it’d take me a full week to actually track down all the js libs on the developer webasites (many are years old), revert changes i made to them (big problem here, realistically i can’t do this, it’ll break the add-on, so i’ll have to look for workarounds, again, this will be a huge, misserable, undertaking), and then still have no guaranteed my add-on will be signed.

And then in a few versions, ff will move to a new api for add-ons; webextensions, which undoubtedly requires more than a few fixes to the add-on. At the very least you could ask add-on makers to deal with such a large re-coding effort once, and require signing at the same time the move is made to webextensions.

I was a upset when chrome required hosted extensions in order to not block them, they even demands me to create a paid (ok, only E 5,-) developer account to host my extension!!! But in hindsight that is nothing to the pressure firefox puts on me to get my add-on working in the latest ff browser. At least chrome didn’t stonewall me, the same (well 90%, only some changes were made to use ff’s addon-api instead of chrome’s) extension which is now blocked in ff is ok in chrome. It’s really a shame.

Not really sure where to go with this, for my add-on, there is no workable way for me to get it working in a ff that requires signed add-ons, maybe once the webextensions api is live i’ll look at it and see how it changes things.

One thing would be nice though: Be more forthcoming with the exact code that block signing cause asking such a huge effort from add-on developers while only listing potential problems (my addon had 80 warnings all from the various js libs) isn’t helping. If, for example, i knew it was a mootools lib that’s causing problems, i could try and fix that lib or work around using that lib, but now i’m simply in the dark.

Part of your code that produces warnings is minified or obfuscated, so I don’t know whether it’s that helpful to point to a minified line with thousands and thousands of characters.

Furthermore, we have a whitelist for a range of third-party libraries and allow them despite the warnings that they throw.
That’s why we need to be able to distinguish between your own code and third-party code.

Any comparisons to the chrome store is invalid as they have a different extension structure with a very limited API which is easy to automatically test against. This is not true for Firefox Add-ons which can basically do anyything they want.

I got the same reply yesterday when I originally submitted the official unminified version. I think we might want to check the automated script that is doing this. I don’t think its the reviewers fault, but the script that compares the libs.

Your fixes to the libs are valid. Just share that with the reviewer. Its absolutely fair for them to think it was tampered, and it is absolutely right of you to tell them yes I tampered with it to fix it. They’ll understand. You just had to write a single line email reply back to the reviewer rather then this huge rant haha but I understand where you’re coming from.

Please let me know which add-on this was about, so I can check what went wrong.

EDIT: Got the information.

1 Like

Thanks very much for your help on irc man! Problem fixed :slight_smile: