Platform/Layout/Triage

Summary

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

Components We Triage

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

• CSS Parsing and Computation
• CSS Transitions and Animations
• DOM: CSS Object Model
• Layout
• 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
• SVG

Triage Guidelines

Note: As of May 4, 2020, Mozilla has moved to a triage process that requires triage of bugs by severity rather than priority. The following guidelines apply to this new process. Bugs that were filed prior to this changeover may have already been triaged using priority, and thus have an empty (`--`) severity field. We have no plans to perform a mass migration of these older bugs, but will instead re-triage them as necessary if they become part of our active backlog.

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.

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 Levels

Severity levels in Bugzilla are designated S1 - S4, in decreasing order.

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 already on the layout backlog.
• Triage Discuss Bugs: Bugs that have been specifically tagged with the [layout:triage-discuss] whiteboard label.
• CSS Working Group Resolutions: Resolutions from the CSSWG for which we should decide whether or not to file a bug.