Summary

This page contains information related to bug triage processes and procedures for Gecko layout and CSS bugs.

Components

The following are the Bugzilla components in the Core product that the Platform Layout team is responsible for:

• CSS Parsing and Computation
• CSS Transitions and Animations
• DOM: CSS Object Model
• Layout
• Layout: Block and Inline
• Layout: Columns
• Layout: Flexbox
• Layout: Floats
• Layout: Form
• 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
• SVG

Triage Guidelines

The definition of Triaged is bugs of type defect where the component is not UNTRIAGED, and a Severity value not equal to -- or N/A.
Bugs of type Task or Enhancement may have a Severity of N/A, but defects must have a Severity that is neither -- nor N/A.

For an overview of Bugzilla triage see the documentation Triage for Bugzilla

How To Triage

Ensure that the bug is in the proper component. Is it a Layout bug? If not, move it to a more appropriate component and allow the triage owners of that component to take over from there.

Otherwise, if you can reproduce the bug:

1. Change its status from UNCONFIRMED to NEW.
2. Set the severity of the bug using the guidance on severity listed below.
3. Preferably, provide a brief comment as to why you believe the bug meets the criteria of the severity you are setting.

If you cannot reproduce the bug:

• Do not set the severity until the bug can be reproduced. Leave it in UNCONFIRMED status.
• Consider asking the reporter for more information or a reduced test case if possible. (Make sure you need-info the reporter as part of your comment.)
• Consider asking others more familiar with the affected component to try and reproduce.
• Consider asking for QA support (MoCo employees only).

Severity

Severity levels in Bugzilla are designated S1 - S4, in decreasing order. For a bug to be considered triaged, the severity level on the bug must be set. Generally, only Mozilla Layout team members or other designated contributors should be setting severity levels on bugs in layout or CSS-related components. Bugzilla users without edit bug access do not have the ability to set severity.

S1 - Catastrophic

Blocks development/testing, may impact more than 25% of users, causes data loss, potential chemspill, and no workaround available. Encountering an S1 layout bug should be very rare!

Examples of S1 layout bugs:

• Any security bug with the sec-critical keyword
• Bugs that cause severe layout breakage on high-traffic sites, particularly breakage that results in missing or unintentionally hidden content
• Layout bugs that break the browser user interface in significant ways
• Most startup crashes, unless very, very low-volume
• Crashes on frequently-visited sites, or printing crashes that affect many users

S2 - Serious

Major functionality/product severely impaired and a satisfactory workaround doesn't exist.

Examples of S2 layout bugs:

• Any security bugs with the sec-high keyword
• Very, very low-volume startup crashes
• Most other crashes unless they are very, very low volume
• Severe performance issues, such as very long restyle times or very long reflows, particularly if affecting frequently-visited sites
• Bugs that cause obviously visible broken layout or unintentionally hidden content
• Print output bugs that cause data loss (such as missing pages, missing content)
• Webcompat issues that cause more than minor cosmetic site breakage, particularly those for which a work around is cumbersome, tedious or difficult for authors to deploy

S3 - Normal

Blocks non-critical functionality and a work around exists

Examples of S3 layout bugs:

• Most sec-moderate and sec-low security bugs
• Very, very low-volume crashes
• Small webcompat issues that authors can work around in a relatively easy way
• Smaller cosmetic issues on frequently-visited sites
• Layout breakages that do not cause issues accessing/viewing content on any site
• Most smaller to medium-sized performance issues, where performance is not a severe impediment to accessing a site for either desktop or mobile users

S4 - Small/Trivial

Minor significance, cosmetic issues, low or no impact to users

Examples of S4 layout bugs:

• Code cleanliness issues — cleanups — that don’t directly impact users
• Minor cosmetic issues that are not noticeable to most users (e.g. 1px “off”, small alignment bugs, minor rendering differences from competing browsers, unexpected scrollbars, unwanted table borders)
• Minor cosmetic issues related to printing
• Minor line breaking, hyphenation or ligature issues
• Other edge case layout issues — even webcompat issues — that are rarely encountered "in the wild"
• Minor spec conformance issues that are rarely encountered
• Most WPT failure bugs from upstream changes

Common Triage Queries

A list of commonly-used Bugzilla queries for untriaged and recently-triaged bugs:

• Recent Untriaged Layout Bugs: Bugs for all layout components that were created in the last 30 days and do not yet have a set severity.
• Recently Triaged to S1 or S2: Bugs that were triaged at S1 or S2 in the last 30 days, are not stalled, and not resolved.
• CSS Working Group Resolutions: Resolutions from the CSSWG for which we should decide whether or not to file a bug.

How We Track Our Backlog

All tracking of backlog and work-in-progress items happens in Bugzilla.

Flags

There are several flag used to track work in Bugzilla including:

• Tracking Flags
• Status Flags
• Project Flags
• Need Info Flags

Assigned

A bug is considered "assigned" if it has both a valid assignee AND its status is set to ASSIGNED. Having only one of these fields set is not sufficient for it to be tracked as an assigned bug. nobody[at]mozilla.org is not a valid assignee for a bug to be considered assigned.

Common Backlog Queries

• Untriaged Defects
• Unassigned S1 and S2 Defects
• Triaged S1 and S2 Defects
• Entire Layout Backlog: All bugs that have been tagged as backlog candidates or are on the official backlog. For more detailed backlog tracking see our backlog page.
• High-Priority Quality Bugs: Backlog items specifically related to improving product quality (not new features/enhancements) that will improve Firefox for many sites or users. Bugs in this list should meet at least one of the following criteria:
  • Known webcompat bug of some significance (P1 or P2 webcompat priority, or otherwise has known webcompat challenges for multiple sites or users)
  • Performance-related bug the fixing of which will likely improve layout performance for multiple sites
  • Bug tracking spec changes that could result in future webcompat issues if left unaddressed
  • Bugs that have been highly-upvoted by users
• Code Quality Bugs: Backlog items related to improving code quality and reducing tech debt. Fixing these bugs should be primarily motivated by improving code cleanliness and developer productivity.