How We Test Across Chrome, Firefox, and Edge

Why cross-browser matters for a calendar extension

Contractors do not get to pick their browser. Client A might require Chrome because their internal tools only work there. Client B mandates Edge because their IT policy pushes it. And your personal browser might be Firefox because you value the privacy features. A calendar aggregation tool that only works in one browser forces you to consolidate, and consolidation might not be an option.

That is why manyCalendars ships builds for Chrome, Firefox, and Edge. Same features, same interface, same data format. But getting there is harder than it sounds, because browser extensions are not as standardized as you might think.

Chromium vs Firefox: the architecture split

Chrome and Edge are both built on Chromium, which means they share an extension architecture. They use the same manifest format, the same APIs, and largely the same behavior. An extension built for Chrome will usually run on Edge with minimal changes. This is the easy part.

Firefox is a different story. While Mozilla has adopted much of the WebExtensions standard that Chrome pioneered, there are meaningful differences in implementation. Storage APIs behave slightly differently. Content script injection timing varies. Background page lifecycle management follows different rules. And some Chrome APIs simply do not exist in Firefox, or exist under different names with different parameters.

For manyCalendars, the biggest difference is in how background scripts work. Chrome moved to service workers with Manifest V3, meaning the background script can be terminated when idle and must be designed to restart cleanly. Firefox still supports persistent background pages in Manifest V2, and their Manifest V3 implementation handles lifecycle differently. Our background logic, which manages calendar data aggregation and conflict detection, must work correctly regardless of whether it might be terminated mid-operation.

Manifest V3 vs V2

Manifest V3 is Google's newer extension platform specification. It replaced persistent background pages with service workers, restricted remote code execution, and changed how network requests are intercepted. Chrome requires Manifest V3 for all new extensions. Edge follows suit, since it is Chromium-based.

Firefox supports both Manifest V2 and V3, and their V3 implementation has some differences from Chrome's. For manyCalendars, we maintain a Manifest V3 build for Chrome and Edge, and a build that targets Firefox's specific V3 implementation with appropriate polyfills where behavior diverges.

The practical impact: features that rely on background processing (like periodic calendar syncing again or conflict detection updates) must be designed around the service worker lifecycle. If Chrome decides to terminate our service worker, we need to resume cleanly when it restarts. Firefox is more forgiving here, but we code for the stricter environment so the extension works correctly everywhere.

Ensuring feature parity

Our test suite runs the same functional tests across all three browsers. Every feature gets verified in Chrome, Firefox, and Edge before a release ships. The test matrix covers:

Tab Sync. Does the content script correctly extract events from Google Calendar, Outlook Web, and ICS feed pages in each browser? Calendar providers occasionally change their DOM structure, and browsers render the same page slightly differently.

Storage and sync. Does calendar data persist correctly in each browser's local storage implementation? Are there size limits we are hitting in one browser but not another?

Popup and sidebar rendering. Does the manyCalendars interface render identically? Font rendering, scrollbar behavior, and CSS grid support have subtle differences across browser engines.

Permission prompts. Each browser presents extension permission requests differently. We verify that the install flow and permission grants work as expected in each environment.

The build script that keeps them in sync

We maintain a single source codebase. The browser-specific differences are handled by a build script that produces three separate extension packages from the same source. The script handles manifest generation (V3 for Chrome and Edge, Firefox-compatible V3 with appropriate adjustments), API polyfills (wrapping Chrome-specific APIs for Firefox compatibility), and platform-specific assets (icons at different resolutions, store listing screenshots).

When a developer makes a change, the build script produces all three packages. CI runs the test suite against each one. If any browser-specific test fails, the build fails. This ensures we never ship a feature that works in Chrome but breaks in Firefox.

The cost is build complexity. The benefit is confidence. When we say a feature works in your browser, it has been verified in your browser. Not just tested in Chrome and assumed to work everywhere else.

Why we do not just tell everyone to use Chrome

It would be simpler. One build, one test matrix, one store listing. But our users are contractors who work across multiple organizations, and those organizations make browser decisions for them. Telling a consultant "just use Chrome" when their client requires Edge for compliance reasons is not helpful. It is dismissive.

So we do the work. Three builds, three test environments, three store submissions every release. It is more effort, but it means manyCalendars works wherever you work, regardless of what browser your clients put in front of you. Pick your browser, install manyCalendars, and trust that it was tested exactly where you are running it. We are a little obsessive about this. You are welcome.