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 https://github.com/mozilla/addons-linter/issues/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]

OK, if I am right?, according to Firefox Doc, we can submit our raw code base, as is in our git repository (not builded nor minified, but with building instructions and info).

This should do because the review will pass the file size check, as our files are in distinct modules at start...

https://extensionworkshop.com/documentation/publish/source-code-submission/

[Nick-1979]

@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.

[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

[mhabsaoui]

After some digging and assets folder refactoring, the Prod mode does its job and the output options.js file is back to normal size (1,3 MB). Don't know for sure if it's realted to the fact of upgradin Webpack and the args.mode usage in its config file...

[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.