Add-on reverted to a 2-year-old version, huge breaking changes for our users

Add-ons Add-on Support
#1

Without any changes to our build config, our latest publish has been rejected, and have been reverted back back to a two-year-old version. A huge breaking change, and users are slowly updating to this very old, breaking version. From version 6.8.0 back to a version from July 2021.

Our extension is an open-source crypto wallet, instructions to build are in the readme.md. Code bundled/concatenated with Webpack, but not minified or obfuscated.

The rejection message is a standard response, yet as far as I understand we are following all of the rules.

Is anyone able to help clarify what rules specific our build is breaking? Why did it take 2 years us to find out our build was breaking the rules?

1 Like
#2

Apologies for missing this post @kyran. Let me see what I can find out.

#3

OK, I see you are in conversation with the review team.

#4

Hi @Edward_Sullivan,

Once more, our extension has been rejected with the same boilerplate message, despite the fact our code is open source and has Firefox review specific build instructions.

Without additional information, we can’t possibly know what’s wrong. We are following all the rules mentioned in the documentation.

Are you able to help us figure out what’s wrong? We may have to soon delist our extension entirely, as we cannot continue to serve a 2 year old version.

For example, why were our extensions approved for 2 years, and then all of a sudden rejected, despite nothing having changed?

Any help appreciated

#5

Hey there @kyran, let me see what I can find out.

#6

Is this the feedback you aren’t clear on?

“1) Your add-on contains minified, concatenated or otherwise machine-generated code. If you haven’t done so, you need to provide the original sources, together with instructions on how to generate the exact same code used in the add-on. Source code must be provided as an archive and uploaded using the source code upload field, which can be done during submission or on the version page in the developer hub. Please read through the instructions at https://extensionworkshop.com/documentation/publish/source-code-submission/ .”

#7

Over the many years I’ve dealt with these issues too so let me give you some tips and tricks.

  1. remember that the reviewer is just a human, probably some lazy programmer like you and me :slight_smile:. So make build process as simple as possible! Ideally “npm i” followed by “npm run build_firefox”, or something similar.

  2. make sure to submit your “package-lock.json” file (I’m not sure if this applies to your “yarn” though).

  3. test it yourself, ideally in linux environment since that’s what reviewers will use! You can use Virtualbox if you are on Windows.

I’ve noticed you’ve wrote this in your github:

Note that when building in a clean environment, some code may vary between this and the submitted build. This is because some variables are set within the scope of the production build’s CI.

This is unacceptable :upside_down_face:
No matter how small the differences are, there is no good reason for them to be there.
Nobody will go and check to see what’s different and how big a security risk it possesses.

I had a huge issues with some webpack plugin that was generating “\r\n” on my Windows but “\n” on Linux and even that was not acceptable.

Alternatively, now that I think about it, you could maybe disable minifation for the final build?

1 Like
#8

Thanks for feedback. To your points:

  1. There’s copy paste code in the readme, but yes we can make a single NPM command
  2. yarn.lock is committed
  3. Tested on Linux

It’s quite normal to use environment-specific build secrets/variables. We do this for Chrome, have always done this on Firefox, and only has it just become an issue?

The reality is that Firefox is < 1% of our userbase, and the amount of time being put into this makes us question whether it’s worth it.

I still believe this is an error on Mozilla’s part.