Verifying the problem before filing

Before you open a browser bug, confirm the behavior you're seeing isn't the intended behavior. Start by checking relevant API documentation on MDN and related specifications. These resources clarify which API is broken, where, and what the expected behavior should be.

Test the page in the latest versions of Chrome, Firefox, Safari, and Edge. If the behavior differs between browsers, it's likely an interoperability issue, especially when the browser with the anomaly is the odd one out. Tools like BrowserStack can help you test across browsers and versions.

Make sure your page isn't responding differently because of user-agent sniffing. In Chrome DevTools, try setting the User-Agent string to another browser before concluding there's a bug.

Check for regressions

If you're aware the behavior worked in a previous release, that's critical information. Regressions are usually acted on much quicker, especially when you can provide a version number where the behavior worked and one where it failed. You can use tools like bisect-builds (for Chromium) to pinpoint the exact change that caused the breakage.

Often, a reproduced regression's root cause is found and fixed quickly. So consider that a high-priority bug to report.

Search for existing reports

If the problem you're facing seems abstract, search Stack Overflow first. That can help you translate it into a specific broken API and point you to a workaround while the bug is pending.

When you have a clear idea of what's broken, search the relevant bug tracker:

  • Chromium-based browsers: https://crbug.com
  • Firefox: https://bugzilla.mozilla.org/
  • Safari & WebKit-based browsers: https://bugs.webkit.org/

If the issue is already reported, add yourself to the CC list and star, favorite, or comment to signal your support. When you comment, mention how the bug affects your website—but avoid "+1"-style comments, since trackers email everyone with each addition.

Create a minimized test case

The single most effective thing you can do is provide a minimal code sample reproducing the problem. A clearly described bug with a demo is better than a description alone. The example must contain the smallest possible amount of code relevant to the issue.

To minimize a test case:

  • Download the page, add <base href="https://original.url">, and confirm the bug happens locally. If the original URL uses HTTPS, you may need a local HTTPS server to allow the local copy to load.
  • Run the local file on the latest builds of several browsers to check whether it's isolated.
  • Combine everything into a single file where you can, then remove code in chunks until the issue disappears.
  • Keep the intermediate versions in source control so you can easily revert your steps.

Once you have a minimal page, host it somewhere persistent:

  • Glitch
  • JSBin
  • JSFiddle
  • CodePen

These services often embed content in an iframe, so the problem may behave slightly differently than it does on a standalone page.

Filing the bug with quality details

Once the test case is ready, head to the correct bug tracker for the browser in question: crbug.com/new for Chromium, Bugzilla for Firefox, and bugs.webkit.org for Safari and WebKit. Then write a report with a focused description that lets the engineer quickly grasp the problem for triage.

Include reproduction steps and expected results

Describe the precise sequence of steps required to reproduce the issue. Reference the URL of your hosted or attached minimal test case so the engineer has a direct way to see the problem. And include the expected behavior compared with what actually happened.

Add screenshots or screencasts for tricky visuals

A screenshot or screencast isn't required, but it is particularly helpful when bugs only surface after several steps or conditions that are hard to describe clearly in text. A visual record conveys what happened more concretely for those examining the report.

List the test environment details

Define your operating system, browser version, display type (high-DPI or low-DPI), and any other relevant configuration. Include details for all environments you tried—these can be crucial for bugs that only appear under certain hardware or OS contexts.

Submit and follow up

File the issue and keep an eye on your email for messages on the bug. Engineers may need clarifications or additional details if they have trouble reproducing the problem. If you have included a version number where the behavior worked and a minimized test case, your report is likely to move through the tracker quickly.