Engineering service
Firefox Browser Extension Development
We build production Firefox WebExtensions and port Chrome extensions to Firefox without forking the codebase: event-page background logic, browser.* compatibility, managed deployment and addons.mozilla.org review.
- 15+ years of experience
- 300+ projects delivered
- Clients worldwide
- NDA available
Overview
What this is, and when it is the right call
Firefox extensions use the WebExtensions API, which is largely compatible with Chrome but not identical. The differences show up in the background model, some API details, the extension ID and the way the store reviews code.
We build Firefox extensions to work alongside a Chrome build where you want both, usually from one codebase with small manifest and API differences. We also build Firefox-first extensions, and prepare the submission so a reviewer can follow it.
Who this is for
- Teams that have a Chrome extension and want a Firefox version from the same codebase.
- Products whose users lean toward Firefox for privacy, or who run it in managed environments.
- Developers who received a review request from addons.mozilla.org and need help preparing source and build instructions.
- Companies that need to roll out a Firefox extension to employees using Firefox policies.
How it works
Architecture at a glance
How a Firefox WebExtension is put together
Popup, side panel, options
The interface users see. Talks to the background through messages.
Service worker (background)
Handles events, alarms and network rules. The browser stops it when idle, so state must live in storage.
Content script
Runs inside pages you choose. Can read and change the page, in an isolated JavaScript world.
Browser extension APIs
tabs, storage, scripting, alarms, declarative network rules, identity
Web page
Content you do not control. Treat everything from it as untrusted input.
What we offer
What we engineer: Firefox Browser Extension Development
Event page background logic
Background scripts written as non-persistent event pages that save state to storage and react to events, since Firefox unloads them when idle.
browser.* API layer with a compatibility shim
Code built on the promise-based browser namespace, with a small shim for the handful of places where Chrome and Firefox behave differently.
Manifest and browser_specific_settings setup
A manifest with browser_specific_settings.gecko.id configured correctly for signing and for storage tied to your extension ID.
AMO submission and source review prep
Submission for signing on addons.mozilla.org, plus a readable source archive and build steps when your code is bundled or minified.
Managed Firefox deployment
Policy configuration so administrators can install the extension on managed machines through Firefox's enterprise policies.
Chrome-to-Firefox porting
Taking an existing Chrome extension and adjusting its background model, manifest and API calls so it runs correctly in Firefox.
Deliverables
What you get
- 01
Firefox manifest
A manifest with browser_specific_settings.gecko.id set, and the Firefox-specific keys handled next to a shared base with your Chrome build.
- 02
Event page background logic
Background code written as a non-persistent event page that saves state to storage and reacts to events instead of assuming it stays loaded.
- 03
Cross-browser API layer
Code that uses the browser namespace with promises, with a small compatibility layer where Chrome and Firefox behave differently.
- 04
Signed, installable builds
Builds submitted for signing so they install in release Firefox, either listed on addons.mozilla.org or self-distributed.
- 05
Source submission package
When code is bundled or minified, a readable source archive and build instructions that reviewers can reproduce.
- 06
Enterprise deployment notes
Guidance on installing the extension through Firefox policies for managed machines, where that applies to you.
Compare
Chrome and Firefox extensions: the differences
Most extension code is shared. These are the places where the two browsers diverge. Check Mozilla's current documentation for Manifest V2 support, since its status is different from Chrome's.
| Area | Chrome | Firefox |
|---|---|---|
| Background in Manifest V3 | A service worker that the browser stops when idle. | An event page, a non-persistent background script. It is also unloaded when idle, so state still belongs in storage. |
| API namespace | chrome.*, with promises supported in Manifest V3. | browser.* with promises. chrome.* also works for compatibility. |
| Extension ID | Assigned by the store when the extension is uploaded. | Set in the manifest with browser_specific_settings.gecko.id, and used for signing and settings storage. |
| Store and review | Chrome Web Store. | addons.mozilla.org (AMO). Extensions must be signed to install in release Firefox, and self-distribution is possible through signing. |
| Source submission | Not normally requested for a packaged build. | Reviewers may ask for readable source and build steps when the submitted code is bundled or minified. |
Why it matters
What this gives you
Event pages handled without assuming persistence
State is kept in storage from the start, so the extension works correctly when Firefox unloads the background script.
Signing and AMO review readiness
Builds submitted with a reproducible source archive when the package is bundled or minified, matching what AMO reviewers ask for.
A path to managed deployment
Policy settings prepared for IT teams that need to roll the extension out to Firefox on company-managed machines.
Groundwork for a shared codebase
Firefox-specific manifest and API differences kept in a thin layer, so the same core logic can serve a Chrome build too.
Our approach
How a Firefox extension project runs
Compatibility review
We go through the APIs and manifest keys your extension uses and note which ones Firefox supports, changes or lacks.
You get: A list of differences and what to do about each
Shared codebase
We set up one source tree with a shared core and small per-browser manifest and API differences, so fixes reach both builds.
You get: A project that builds for each browser
Build and test in Firefox
We test in Firefox itself, including event page unloading, permission prompts and the behavior of content scripts on the target sites.
You get: A working Firefox build
Sign and submit
We prepare the source archive if needed, submit for signing, and answer reviewer questions with you.
You get: A signed build and a submitted listing
Maintain both builds
We document the release steps so future Chrome and Firefox updates go out from the same source.
You get: Release notes for your team
When this is not the right fit
A few cases where this approach may not be the best choice for you.
- Your extension depends on Chrome-only APIs with no Firefox equivalent. We will tell you what to drop or rebuild.
- You want to run the extension in Firefox without signing. Release Firefox requires signed extensions.
- You want a Firefox browser fork with built-in features. That is browser modification, a different service.
Tech stack
Technologies we use
The engines, APIs and tools behind our firefox browser extension development work.
JavaScript
TypeScriptFAQ
Questions engineers ask before starting
Usually yes. The core logic is shared, and the differences are small: the manifest, the background model and a few API behaviors. We keep those in a thin layer so the shared code stays the same.
Our services
Related services
Explore more services that work alongside this one.
Talk to a Browser Engineer
Bring Your Extension to Firefox Properly
Send us your Chrome extension or your Firefox requirements. We will map the differences and the path to one shared codebase.
