Whenever you're building, if ./mach build was previously run and you have not made any changes to C++ or Rust code (nor rebased past incoming changes to such code), you can use ./mach build faster to skip the compilation and linking steps and only build the front-end code. This can save a lot of time when you're only working on the browser/ or toolkit/ code.
CSS should use reusable tokens from the design system (in toolkit/themes/shared/design-system) wherever possible, to ensure consistent UI and to make it easy to change styles across the board.
Use reusable components for common UI patterns. These components live in toolkit/content/widgets/. A storybook instance for these components can be accessed on https://firefoxux.github.io/firefox-desktop-components/. It is fine to use in-development components.
Use CSS logical properties (e.g. margin-inline-start instead of margin-left) for better localization support.
Avoid setting styles in JavaScript. Set a class instead and specify styles in CSS.
Use semantic HTML elements whenever possible. For example, use <a> for links, <moz-button> or <button> for buttons, etc. This helps accessibility and makes the code easier to understand.
When writing JavaScript, prefer using modern ES6+ syntax and features. For example, use let instead of var, and use arrow functions where appropriate.
Firefox has special XUL elements specifically for floating panels (<panel>), tooltips (<tooltip>) and menus (<menupopup>, <menuitem>, <menu> and <menuseparator>). Use these elements when appropriate, as they provide built-in behavior and accessibility features.
For strings appearing in the interface, always use localized strings so they can be translated to support different locales.
For new code, use Fluent (.ftl files). Do not use legacy string systems. Check if strings already exist before creating new ones.
Firefox for Desktop needs to run successfully on Windows 10, Windows 11, macOS 10.15+, and Linux.
Toolkit code may be shared with Android, as well as desktop versions of Thunderbird, so do not assume that code from the browser/ directory is available for use from there - if it must be used, make sure that the toolkit/ code can recover if it is not available.
Ensure that your changes are accessible and work well with assistive technologies. Use semantic HTML elements, ARIA attributes, and test with screen readers and keyboard navigation.
Ensure that your changes are performant and do not cause jank or slow down the browser. Use performance profiling tools to identify and fix any performance issues.
When touching Firefox front-end code, read docs/performance/bestpractices.md to learn more about performance best practices and how to avoid common pitfalls (for example, forcing synchronous layout flushes on hot paths).

Más de este repositorio

mismo repositorio

profiler-analysis

mozilla-firefox/firefox

Analyze Firefox performance profiles using the profiler-cli CLI tool. Trigger when given a profiler.firefox.com or share.firefox.dev link, a local profile path, or when the user wants to investigate an issue in a Firefox profile. Always use this skill instead of WebFetch for Firefox profiler URLs; WebFetch only retrieves the profiler UI's HTML shell and cannot access profile data, whereas profiler-cli downloads and parses the actual profile into a local daemon that supports structured queries over stacks, markers, threads, and samples.

2026-07-2312.6k

media-patch-review

mozilla-firefox/firefox

Reviews dom/media code changes ONLY — not any other component. Fans out the in-tree dom/media review checklists (dom/media/docs/review/*.md) against a patch, one opus reviewer per checklist, then collects the findings. Temporary local tool until bugbug's /patch_review loads these docs directly. Triggers on: "media-patch-review", "/media-patch-review".

2026-07-1712.6k

stmo

mozilla-firefox/firefox

Manage Redash queries and dashboards on Mozilla's STMO (sql.telemetry.mozilla.org) using stmo-cli. Use when the user wants to explore telemetry data on STMO, write, deploy, or execute Redash queries, manage dashboards, or discover data sources. Also trigger on mentions of STMO, Redash, sql.telemetry.mozilla.org, or when the user wants to query Mozilla telemetry data (as opposed to probe/metric discovery, which is mozdata territory).

2026-07-1712.6k

find-reviewer

mozilla-firefox/firefox

Find the right reviewer for a Firefox/Gecko change so the user does not have to. Use this primarily when committing changes, to fill in the `r=` part of the commit message automatically instead of leaving it blank or guessing. Also use it when the user asks directly who should review a patch or what reviewer group to use.

2026-07-1012.6k

android-new-module

mozilla-firefox/firefox

Guide for creating new Android gradle modules in the android-components project.

2026-07-0712.6k

documentation

mozilla-firefox/firefox

Use this skill when working with Firefox documentation, including building documentation with `./mach doc`, fixing Sphinx build errors or warnings, modifying existing documentation, or adding new docs.

2026-07-0112.6k

name	firefox-desktop-frontend
description	You MUST use this skill when working with HTML, JS, CSS and other front-end code.

Workflow

Whenever you're building, if ./mach build was previously run and you have not made any changes to C++ or Rust code (nor rebased past incoming changes to such code), you can use ./mach build faster to skip the compilation and linking steps and only build the front-end code. This can save a lot of time when you're only working on the browser/ or toolkit/ code.
CSS should use reusable tokens from the design system (in toolkit/themes/shared/design-system) wherever possible, to ensure consistent UI and to make it easy to change styles across the board.
Use reusable components for common UI patterns. These components live in toolkit/content/widgets/. A storybook instance for these components can be accessed on https://firefoxux.github.io/firefox-desktop-components/. It is fine to use in-development components.
Use CSS logical properties (e.g. margin-inline-start instead of margin-left) for better localization support.
Avoid setting styles in JavaScript. Set a class instead and specify styles in CSS.
Use semantic HTML elements whenever possible. For example, use <a> for links, <moz-button> or <button> for buttons, etc. This helps accessibility and makes the code easier to understand.
When writing JavaScript, prefer using modern ES6+ syntax and features. For example, use let instead of var, and use arrow functions where appropriate.
Firefox has special XUL elements specifically for floating panels (<panel>), tooltips (<tooltip>) and menus (<menupopup>, <menuitem>, <menu> and <menuseparator>). Use these elements when appropriate, as they provide built-in behavior and accessibility features.
For strings appearing in the interface, always use localized strings so they can be translated to support different locales.
For new code, use Fluent (.ftl files). Do not use legacy string systems. Check if strings already exist before creating new ones.
Firefox for Desktop needs to run successfully on Windows 10, Windows 11, macOS 10.15+, and Linux.
Toolkit code may be shared with Android, as well as desktop versions of Thunderbird, so do not assume that code from the browser/ directory is available for use from there - if it must be used, make sure that the toolkit/ code can recover if it is not available.
Ensure that your changes are accessible and work well with assistive technologies. Use semantic HTML elements, ARIA attributes, and test with screen readers and keyboard navigation.
Ensure that your changes are performant and do not cause jank or slow down the browser. Use performance profiling tools to identify and fix any performance issues.
When touching Firefox front-end code, read docs/performance/bestpractices.md to learn more about performance best practices and how to avoid common pitfalls (for example, forcing synchronous layout flushes on hot paths).