Your review process is hurting companies

Add-ons addons.mozilla.org
#1

Hey guys,

I mean, we really appreciate the work you are doing and that you want to guarantee safety of users and quality of extensions, but there is something seriously wrong with the current process!

First time it took around two months, just to let us know that our manifest.json contains unsafe-eval script to the official google analytics js. I mean, c’mon, two months? If it is somewhere inside the guidelines, we are sorry, still two months of waiting for this?

We are waiting since 14th of February (almost 2 months) and are still 118th in the queue, which did not change since the last 4 days. And the worst thing, we still do not know how long it will take or if we will ever make it.

Not speaking of before you start to review, we have already several new releases out on other platforms. And some functionality requires to have all the platforms up to date (now Chrome, Safari, iOS, Android), and this is the most tricky part, what should we do about that? Resubmit a new one now and land on position 550 (increases daily) in the queue and wait for months? (at least allow to update the version which is waiting for review without reseting the position, but this still does not solve the long waiting time)

There can be a critical bug, or a platform dependent functionality, which requires the same data format for all platforms, so we need to make workarounds and enable features per platform, which is pretty tricky when you have different data models and encryptions…

Our extension is in the Chrome and Safari Store working totally fine since more than two years and serving more than 50k users, and we are happy to comply with every rule you have, just let us know if we need to change something, and not like after a 15 minute check: “we found something”, and now wait for months for another 15 minute check – “we found something”. So we have no idea if we will be able to cover the Firefox market ever.

To answer why does it hurt us: There is a logical and strategic pressure from investors, partners and customers to cover the Firefox market.

And yes we know: that we should all become reviewers and help Mozilla, which is pretty hard to understand and to explain to investors to be honest. And yes, we have already read several times: the process should improve soon…

And again, thanks for you hard work, we know you are doing your best, but this situation is just getting worse.

Please if we can do anything to get our add-on published, let us know, if we need to allocate development resources to review other add-ons, let us know, how much work is required… (even I do not think this is the proper and a longterm solution).
Extension link is https://goo.gl/JUCmGm (sorry for the shorten link, did not wanted to link this post to our company)

Thanks for any help,
Michal

3 Likes
#2

Your addon is in Admin review queue which can take longer.

It is the complication of having minified/obfuscated code which often has to be checked by Admin Reviewers (I am not and Admin reviewer).

Mozilla cares more about security of addons and their users and that is why the code has to checked. Other browser are relaxed about these issues and the result is a lot of malware ending up being distributed.

I had a very quick look over the code for you and here are a few notes that you might find useful.

Minimizing normal (non-library) code, HTML or CSS, serves no real purpose but complicates the review process and adds to your waiting time. They may have to be checked by an admin reviewer which may take longer.

The “src/background/ga.js” will result in rejection due to its extensive tracking by Google.
Of course, Google themselves would not object if extension developers include their tracking code.

Please see https://blog.mozilla.org/addons/2016/05/31/using-google-analytics-in-extensions/ for a proper way to do this.

src/content_scripts/popups/accounts.css is 700+ KB
src/content_scripts/popups/login.css 693 KB
src/ui/bundle-dd9256d33212890404ec-0.js 800KB
Please refrain from including resources as lengthy data:URIs strings, as doing so has performance implications and considerably complicates the review process and adds to your waiting time. Please include them as separate files within your XPI.

Most of the files have large amount of code and some of the files are massive.
src/sp-core/core.js is 2.5 MB of JS code with 74,721 lines of code.
Re-factoring the code could speed up the process.

It is best to avoid using innerHTML (or similar method of converting strings to DOM e.g. outerHTML, insertAdjacentHTML, parseFromString, createContextualFragment, JQuery append/prepend/appendTo/html/before/after/insertBefore/insertAfter).

Please limit web accessible resources to the absolute minimum, as they can pose a privacy and security threat.

I hope that helps.

2 Likes
#3

Hey erosman,

Thank you for your fast reply, we really apreciate it, and if we should ever meet, I will be happy to invite you for a beer!
Trust me, we are not trying to make the job of a reviewer harder.
We agree with all points, and we will implement then, please have a look at the answers and let me know if we missed anything.
Would be great if an Admin could let us know what we should do.

Your addon is in Admin review queue which can take longer.

Yes, but to wait months, to get at least some kind of statement, and to wait maybe years until we get inside the store puts us in to a very complicated situation.

It is the complication of having minified/obfuscated code which often has to be checked by Admin Reviewers (I am not and Admin reviewer).

Therefor we have submitted also unprocessed code, as we have been asked. We are ok, if Mozilla employees get access to our unprocessed code and then they obfuscate it (properly, we can test it in advance with any suggested settings of Mozilla) and publish it.
However, I hope everybody understands, that we cannot provide our IP which equals unprocessed code to 3rd party reviewers where we are not aware of their legal restrictions in connection with our code. I mean, we have no idea if they just do not take it and sell it.

Mozilla cares more about security of addons and their users and that is why the code has to checked. Other browser are relaxed about these issues and the result is a lot of malware ending up being distributed.

Sure, we understand that, and we care too about security. Still as stated up, this is not a well managed process.

I had a very quick look over the code for you and here are a few notes that you might find useful.
Minimizing normal (non-library) code, HTML or CSS, serves no real purpose but complicates the review process and adds to your waiting time. They may have to be checked by an admin reviewer which may take longer.

Already answered.

The “src/background/ga.js” will result in rejection due to its extensive tracking by Google.
Of course, Google themselves would not object if extension developers include their tracking code.
Please see https://blog.mozilla.org/addons/2016/05/31/using-google-analytics-in-extensions/ for a proper way to do this.

We rather kicked it out completely.

src/content_scripts/popups/accounts.css is 700+ KB
src/content_scripts/popups/login.css 693 KB
src/ui/bundle-dd9256d33212890404ec-0.js 800KB

Please refrain from including resources as lengthy data:URIs strings, as doing so has performance implications and considerably complicates the review process and adds to your waiting time. Please include them as separate files within your XPI.

We agree, we had some inline resources, which we will ckick out and split the files.

Most of the files have large amount of code and some of the files are massive.
src/sp-core/core.js is 2.5 MB of JS code with 74,721 lines of code.

We agree, we will split up the files and extracted the text resources in to separate files.

Re-factoring the code could speed up the process.

This happens every few months, still a way to go as we need to stay fast with new functionality.

It is best to avoid using innerHTML (or similar method of converting strings to DOM e.g. outerHTML, insertAdjacentHTML, parseFromString, createContextualFragment, JQuery append/prepend/appendTo/html/before/after/insertBefore/insertAfter).

Yeah, already started to rework this.

Please limit web accessible resources to the absolute minimum, as they can pose a privacy and security threat.

Yes, we already started to make this better.

I hope that helps.

I hope to, thanks for your help.

Would be great if an Admin could let us know what we should do, cause the adaptions you mentioned will be done in few days, but to wait several more months until the two months old version will be reviewed, just to tell us the same points, or if we now submit a new version, which will then end up at position 550 and need maybe another year? We have no idea.

2 Likes
#4

My pleasure… Cheers :slight_smile:

2 Likes
#5

What I noticed is that if you haven’t been reviewed yet (new extension queue), you don’t lose your position in the queue if you upload a new version. It’s only if you upload a new version in the update queue that you get placed in the back of the queue.

1 Like
#6

Thank you for the information, we did not knew that, have not seen it anywhere in the docs :confused:
And another beer goes to Kenny_D :slight_smile:

Still, we do not know what to do if they check the extension again for like 15 minutes and refuse it, and then we need to wait several months again, for another 15 minute check?

1 Like
#7

You could try making your extension unlisted (automatic review) and just self host the signed version on your website. I think that’s what Lastpass does for their beta versions.

2 Likes
#8

Hi Michal,

Thanks for posting this.

We’ve (“Riff”) been in the queue since January 9th. A full 3 months. I suspect we are also in the dreaded admin queue.

The review process hurts companies, but I’d also argue that it hurts Firefox. The more painful the process, the less likely developers are going to put in the effort to support Firefox.

1 Like
#9

Which addon is it? What is the link?

#10

The admin queue being automatically triggered for any “built” code is pretty oppressive given that modern JS development of any complexity typically uses tools like webpack/browserify and babel during development, making “built” code unavoidable.

We’ve been approved already, but our update once again is in admin queue due to our using Babel and Webpack. So, does that mean another 3 month wait like last time? What if this was a critical bug fix and not a feature release?

I’m not going to remove JS modules just to support Firefox. I’m just going to stop supporting Firefox. I don’t want to but y’all are giving no choice considering we can’t even support a bi-weekly release cycle without the FF review process causing log jams.

I understand the main queue is volunteer run so it’s subject to slowdowns sometimes but the thing is we can’t even get into that queue! We are doomed to get into the admin queue hell every time because of our development process.

Something needs to change with the admin review system as it stands now because it’s not in line with the reality of how any even remotely complex JS is written in the year of our lord 2017.

1 Like
#11

The plan for the future is to move to a non-blocking process. We expect to have it in place by the end of the quarter, so for now all we can ask for is patience as we make the necessary changes.

2 Likes