Contribute to Umbral

How to propose reproducible changes without losing persistent sources.

Development builds · Documented status: 4 Nov 2026

Before starting

For large changes, start with a proposal explaining the problem and desired outcome. Code is not the only way to help: clear reports, translations, documentation and platform testing are useful too.

Sources and builds

Work from the Umbral repo root. engine/ is a separate generated repository; do not treat it as the source of truth. Browser changes belong in src/, prefs/, configs/, locales/, surfer.json and their patches. Preserve symlinks and register new resources using the existing packaging flow.

For a new checkout with Mozilla and project prerequisites prepared, use npm ci and npm run init before building. In an initialized tree, import and build current changes. Do not update the pinned base as a side effect of a UI task.

npm run import
MOZ_PURGE_CACHES=1 npm run build:ui
git diff --check

What a change should include

Describe the problem, final behavior, tests performed and their limits. Use temporary profiles; do not attach personal profiles. Distinguish builds, static inspection and runtime verification. Tests should check behavior rather than mirror the implementation.

Credits and scope

Keep license and attribution notices. Do not remove credits or globally rename technical Zen or Firefox references. For security fixes, use the private channel rather than a public PR containing exploitable details.