Request to Increase Extension Upload File Size Limit

[Nick-1979]

Dear Firefox Development Team,

I am writing to inform you of an issue I encountered while attempting to update my extension on Firefox. Unfortunately, despite successfully updating the extension on Chrome and Edge with new features, I am currently unable to do the same on Firefox due to the existing file size limitation.

The error message states that the file size is too large to parse.

I kindly request that you consider increasing the file size limit for extension updates on Firefox. This adjustment would allow developers like me to provide the same enhanced functionality to Firefox users that is already available on other browsers.

Thank you for your attention to this matter. I greatly appreciate the efforts of the Firefox development team and hope for a positive resolution.

┆Issue is synchronized with this Jira Task

[diox]

Hi,

This has already been reported in #4748 for a specific case - tesseract.js.

We have to have some kind of limit to avoid abuse as parsing and analyzing submitted code is time consuming and costly as the size increases.

What limit would work in your case ?

[Nick-1979]

Hi @diox,

Thank you for responding.
I have read that issue before. In my situation, a file size of 15 MB is acceptable.

[diox]

I'm not opposed to a bump to 5 MB - there are several developers that it would benefit and it's been a while since we last increased that limit - but we need to make some internal architecture changes in our private scanners before considering this.

[Nick-1979]

Hello,

I would like to know if there is any progress on resolving this issue or any estimate on when we can update our extensions without encountering this problem.

Thank you for your hard work and attention.

[diox]

Hi,

Sorry for not answering sooner. This is still blocked on migrating infrastructure of our private scanners but we intend to unblock that in January (wanted to do this earlier but we ran into issues when migrating the bulk of AMO infrastructure that pushed this further and now it's too late, we're entering a code/infra freeze for end-of-year holidays). Once this is done and stable there should be no hard blockers left and we should be able to bump that limit.

[Nick-1979]

Hi @diox

I would appreciate it if you could provide an update on this matter.

Thank you!

[diox]

Hi,

Sorry, we're still tracking this, but the infrastructure changes are still in progress.

[Nick-1979]

I'm disappointed to see that this issue is still ongoing after a year. While I understand these problems can be complex to resolve, I had hoped more progress would have been made by now.
I encourage the team to continue working diligently to address this matter in a timely manner. I remain hopeful that a solution can be found soon.

Thank you for your continued efforts on this important matter.

[mhabsaoui]

Hi,

Same here :-/
We just added new features to our addon Click&Read, and the Options.js jumps from 3MB to 4.99MB.

Error: This file is not binary and is too large to parse. Files larger than 4MB will not be parsed. Consider moving large lists of data out of JavaScript files and into JSON files, or splitting very large files into smaller ones. options/options.js

And the limit is 4MB !

Please help us because Mozilla Store on late review deactivated all our addon versions, and asked us to add a Privacy Consent ASAP. We did and now this...

All our new users are stuck.

[mhabsaoui]

@mhabsaoui

"When you upload your extension to AMO, you will need to provide your source code and instructions for building that source code." This means you need to upload your code after uploading the build if it is minified or using webpack.

Yes, indeed just checked with my collegue who's in charge of publishing, first we upload the dist zip, and in case of build tool (our case with Webpack), then we also upload the SRC code zip !

Then, what can we do, only to try to split our features in other Views files ?

Just don't see why :

• why the addon linter isn't applied on raw source code, insted of build dist ?
• we are limited in code size per file (new features adds up code lines/size) ?

Thanks

[dotproto]

why the addon linter isn't applied on raw source code, insted of build dist ?

I see two reasons.

1. The linter is run against the extension code submitted by the developer because that is the code that end users will be installing and running in their browsers.
2. The original languages used to write the extension may not be JavaScript, JSON, etc. "Compile-to-JS" languages are common and it's infeasible for the linter to support all of them.

[qqzm]

It would make my build process so much easier if you could increase this limit to 15MB.

[darioAnongba]

@diox, any update on that increase to 5MB (or more)? I see many posts complaining about this issue for many years now.

Chrome does not have this problem and their Extension Store is working fine.Do you have this limitation because of a limit on resources?

[qqzm]

My issue is with a single JSON data file in my extension. The file is a little over 10MB.

My workaround is to package 4MB of data with the extension and then download the full 10MB file in the background on first launch. But this adds complexity to my build process as I have to compile a full copy of the extension for Chrome, Opera and Edge, then chop the file down to 4MB and create a separate package just for Firefox.

[Juraj-Masiar]

@qqzm another workaround could be to zip it with gzip and then use the new Compression Streams API to unzip it at runtime:
https://developer.mozilla.org/en-US/docs/Web/API/Compression_Streams_API

[qqzm]

@qqzm another workaround could be to zip it with gzip and then use the new Compression Screams API to unzip it at runtime: https://developer.mozilla.org/en-US/docs/Web/API/Compression_Streams_API

Thanks for your suggestion. Unfortunately, zipping it does not get it below 4MB.