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 toinnerHTML
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:
- 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.