The Platform Layout Team is primarily responsible for Gecko's style system and layout engine. We strive to build and maintain an engine that is both high-performance and standards-compliant, while providing support for features unique to Firefox.
The team's technical domains within Gecko include:
- CSS animations and transitions
- CSS parsing and computation
- Layout (of all types, including block and inline, positioned, columns, floats, flexbox, grid, form controls, images, video, tables, and text)
- Matrix/Riot.IM: #layout on chat.mozilla.org
- Slack: #layout on Slack (Mozilla employees and NDA'd contributors only)
- E-mail: Subscribe to firstname.lastname@example.org
Communications Channel Guidelines
- Synchronous discussions about engineering-specific topics (bugs, patches, code reviews, architectural issues, etc.) should happen in #layout on chat.mozilla.org.
- Synchronous discussions about team operations, announcements, strategy, and other banter tend to happen in Slack (private to Mozilla employees and NDA'd contributors), unless such communications can and should be made public.
Roadmap and Status
This project tracker on Trello contains all work-in-progress and backlog items that the team is considering for the near future. Note that this list is subject to change at any time.
For more detailed information, notes from the team's weekly standup meetings are available.
Backlog Tracking in Bugzilla
For more detailed backlog and development information, check the status of things in Bugzilla.
We use the
[layout:backlog] tag in the whiteboard field on bugs, tasks and enhancements to track work items that are either under active development, or being considered for development within the next year.
We use bug priorities to indicate how soon we plan to work on a bug, task or enhancement according to the following classifications (also documented in our Firefox-wide priority definitions):
- P1 — "Must have/fix." Under active development, or planned development for the current release cycle.
- P2 — "Should have/fix." Near-term backlog item, can/will be worked on in the next release cycle or the one following.
- P3 — "Would like to have/fix." Longer-term backlog item, planned to work on within the next year (assuming the bug also has the
- P4 — N/A
- P5 — "Will not fix." No plans to work on this item, but will accept contributor patches.
Commonly-Used Backlog Queries
We publish notes and lists of all fixed layout bugs for a given release. These release notes call out items of particular importance (new features, webcompat fixes) that may be helpful for web content authors.
Bugs and Bugzilla
Filing a Bug
Open a bug under "Product: Core", using one of the following components:
- CSS Parsing and Computation
- CSS Transitions and Animations
- DOM: CSS Object Model
- Layout: Block and Inline
- Layout: Columns
- Layout: Flexbox
- Layout: Floats
- Controls Layout: Form Controls
- Layout: Generated Content, Lists, and Counters
- Layout: Grid
- Layout: Images, Video, and HTML Frames
- Layout: Positioned
- Layout: Ruby
- Layout: Scrolling and Overflow
- Layout: Tables
- Layout: Text and Fonts
- Print Preview
- Printing: Output
- Printing: Setup
Triage Process & Guidelines
If you're curious about how we triage and prioritize bugs, please visit our triage page for more information. This page includes information about our triage process and guidelines, as well as useful triage-related bug queries.
We use the following strings (tags) in the whiteboard field on bugs in Bugzilla to track important metadata:
[layout:backlog]: Indicates the bug is in our backlog, and is either under active development, or planned development for the current year (see bug priority for approximate timeline).
[layout:icebox]: Indicates a bug we are considering including in our backlog in the future, but are unlikely to work on in the current year.
[layout:triage-discuss]: Indicates that we plan to discuss this bug in more detail at one of our internal, bi-weekly triage meetings. Usually this is set if the severity level is disputed, or in question, or other triage details of the bug are unclear.
We also use whiteboard tags to track bugs for longer-running projects. For more information on these projects and their associated tags, see the pages below:
We always welcome new contributors! Here are a few things you can do to get started:
- Read the instructions for building Firefox on developer.mozilla.org.
- Read the programmer's primer on Gecko, particularly the layout section.
- Get familiar with the Mozilla code style guidelines.
If you're looking for a good first bug to fix, the following resources may help: