Add guidelines for packaging Mozilla Firefox extensions

noctua commented

2025-05-06 23:53:53 +00:00

First-time contributor

Added guidelines to package Mozilla Firefox extensions.

limb commented

2025-05-08 16:48:11 +00:00

Owner

How does a packager determine what the gecko id should be?

noctua commented

2025-05-09 17:23:02 +00:00

Author

First-time contributor

It is in the manifest.json file in the field id. If the field id does not exist, as reported in this PR content, the extension cannot work.

It is in the `manifest.json` file in the field `id`. If the field `id` does not exist, as reported in this PR content, the extension cannot work.

limb commented

2025-05-09 17:24:15 +00:00

Owner

So this will be in that file, and that file will exist, in every extension?

noctua commented

2025-05-09 17:24:32 +00:00

Author

First-time contributor

yes. Manifest file is mandatory for each extension.

limb commented

2025-05-09 17:30:32 +00:00

Owner

Ok, thank you!

noctua commented

2025-05-09 17:36:37 +00:00

Author

First-time contributor

rebased onto 6e208c155d

rebased onto 6e208c155d7fa34013b363c5497323cf553c0b01

tibbs commented

2025-05-12 19:34:39 +00:00

Owner

One significant problem I see with this is that it's just not OK to just take the .xpi file from upstream and copy it over and be done, just as it's not acceptable to copy an upstream compiled binary into _bindir. We don't know what's in there; it could have minimized javascript sources or the output of something that compilers to javascript. In fact, I'd argue that even if there wasn't anything but a single javascript file in there, we still shouldn't be shipping the upstream .xpi file.

One of the best-packaged extensions is mozilla-ublock-origin. That spec is way more complicated: it lists out all of the bundled javascript libraries, it invokes the upstream source build script and it recreates all of the .wasm files. I expect that most extensions would be simpler but that the common case is that there is still something bundled or something that needs building.

One significant problem I see with this is that it's just not OK to just take the .xpi file from upstream and copy it over and be done, just as it's not acceptable to copy an upstream compiled binary into _bindir. We don't know what's in there; it could have minimized javascript sources or the output of something that compilers to javascript. In fact, I'd argue that even if there wasn't anything but a single javascript file in there, we still shouldn't be shipping the upstream .xpi file. One of the best-packaged extensions is mozilla-ublock-origin. That spec is way more complicated: it lists out all of the bundled javascript libraries, it invokes the upstream source build script and it recreates all of the .wasm files. I expect that most extensions would be simpler but that the common case is that there is still something bundled or something that needs building.

noctua commented

2025-05-13 19:48:34 +00:00

Author

First-time contributor

If you are concerned about security, I think that the best option should be still to get the .xpi file directly from Mozilla store, because the AMO team actually performs security checks.

uBlock Origin can be packaged in that manner because it is a particular case (give a look to the source repository) and usually, the most of extensions don't have that structure. I think the most generic way is the one described in the proposed PR.

If you are concerned about security, I think that the best option should be still to get the .xpi file directly from Mozilla store, because the AMO team actually performs security checks. uBlock Origin can be packaged in that manner because it is a particular case (give a look to the source repository) and usually, the most of extensions don't have that structure. I think the most generic way is the one described in the proposed PR.

yselkowitz commented

2025-05-13 20:06:12 +00:00

Member

Guidelines already require that code be rebuilt from source. Even if there isn't anything to be rebuilt, I would expect that the .xpi at least be unpacked and repacked (as in the missing ID example) so that the contents can be verified.

rathann commented

2025-05-13 20:15:55 +00:00

Member

This .xpi file should be built from source like any other artifact. See for example mozilla-noscript or mozilla-privacy-badger.

This `.xpi` file should be built from source like any other artifact. See for example [mozilla-noscript](https://src.fedoraproject.org/rpms/mozilla-noscript/blob/rawhide/f/mozilla-noscript.spec) or [mozilla-privacy-badger](https://src.fedoraproject.org/rpms/mozilla-privacy-badger/blob/rawhide/f/mozilla-privacy-badger.spec).

noctua commented

2025-05-13 20:27:59 +00:00

Author

First-time contributor

Yes. I need to change the source and point to their git source repository.

This pull request is broken due to missing fork information.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin my-firefox-extension-docs:my-firefox-extension-docs

git switch my-firefox-extension-docs

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch main

git merge --no-ff my-firefox-extension-docs

git switch my-firefox-extension-docs

git rebase main

git switch main

git merge --ff-only my-firefox-extension-docs

git switch my-firefox-extension-docs

git rebase main

git switch main

git merge --no-ff my-firefox-extension-docs

git switch main

git merge --squash my-firefox-extension-docs

git switch main

git merge --ff-only my-firefox-extension-docs

git switch main

git merge my-firefox-extension-docs

git push origin main

Rows
Columns

Add guidelines for packaging Mozilla Firefox extensions #1462

Checkout

Merge