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