Skip to main content




Informing browser providers about problems you encounter with your browser is an integral part of improving the web platform.


Updated

Filing a good bug isn't difficult, but it does take a bit of work. The goal is to make it easier to find what's broken, get to the root cause, and most importantly, find a way to fix it. Rapidly progressing bugs tend to be easy to reproduce with clear expected behavior.

Verify that it is an error

The first step is to figure out what the "correct" behavior should be.

What is the correct behavior?

See the relevant API docs at MDNor try to find related specifications. This information can help you decide which API is actually broken, where it is broken, and what is the expected behavior.

Does it work in a different browser?

Behavior that differs between browsers is generally prioritized more as an interoperability issue, especially when the browser containing the bug is the outsider. Try testing on the latest versions of Chrome, Firefox, Safari, and Edge, possibly using a tool like BrowserStack.

If possible, verify that the page is not intentionally behaving differently due to user agent tracing. In Chrome DevTools, try configuring the User-Agent string to another browser.

Did it break on a recent release?

It worked as expected in the past, but it broke in a recent version of the browser? Such "regressions" can be acted upon much faster, especially if you provide a version number where it worked and a version where it failed. Tools like
BrowserStack it can make it easier to check old versions of the browser.

If a problem is regression and can be reproduced, the root cause can usually be found and fixed quickly.

Are others seeing the same problem?

If you're having problems, chances are good that other developers are too. First, try looking for the error in Stack overflow. This could help you translate an abstract problem into a specific broken API and could help you find a short-term fix until the bug is fixed.

Has it been reported before?

Once you have an idea of what the error is, it's time to check if the error has already been reported by searching the browser's error database.

If you find an existing bug that describes the problem, please add your support by highlighting, bookmarking, or commenting on the bug. And on many sites, you can add yourself to the CC list and get updates when the error changes.

If you decide to comment on the bug, please include information on how the bug affects your website. Avoid adding "+1" style comments, as bug trackers often send emails for each comment.

Report the bug

If the error has not been reported before, it is time to inform the browser provider.

Create a minimized test case

Mozilla has a great article on
how to create a minimized test case. To make a long story short, while a description of the problem is a great start, nothing better than providing a demo linked on the error that shows the problem. To maximize the possibility of rapid progress, the example should contain the minimum possible code necessary to demonstrate the problem. A minimal code sample is the first thing you can do to increase the chances that your bug will be fixed.

Here are some tips for minimizing a test case:

  • Download the web page, add

    and verify that the error exists locally. This may require an active HTTPS server if the URL uses HTTPS.

  • Try local files in the latest versions of as many browsers as you can.
  • Try to condense everything into 1 file.
  • Eliminate the code (starting with things that you know are unnecessary) until the error is gone.
  • Use version control so you can save your work and undo the things that went wrong.

Host a minified test case

If you are looking for a good place to host your minified test case, there are several good places available:

Note that several of those sites display content in an iframe, which can cause functions or errors to behave differently.

Present your problem

Once you have your test case minimized, you are ready to file that bug. Go to the correct bug tracking site and create a new issue.

Provide a clear description and steps to reproduce the problem.

First, provide a clear description to help engineers quickly understand what the problem is and help classify the problem.

When installing a PWA using the `beforeinstallprompt.prompt ()`, the
`appinstalled` event fires before the call to` prompt () `resolves.

Please provide the detailed steps required to reproduce the problem below. This is where your minified test case comes in.

What steps will reproduce the problem?
1. Go to https://basic-pwa.glitch.me/, open DevTools and look at the
console tab.
2. Click the Install button in the page, you might need to interact with
the page a bit before it becomes enabled.
3. Click Install on the browser modal install confirmation.

And finally, describe the realand expected result.

What is the actual result? In the console:
0. INSTALL: Available (logged when `beforeinstallprompt` event fired)
1. INSTALL: Success (logged when `appinstalled` event fired)
2. INSTALL_PROMPT_RESPONSE: {outcome: "accepted", platform: "web"}
(logged when beforeinstallprompt.prompt () `resolves)

What is the expected result? In the console:
0. INSTALL: Available (logged when `beforeinstallprompt` event fired)
1. INSTALL_PROMPT_RESPONSE: {outcome: "accepted", platform: "web"}
(logged when beforeinstallprompt.prompt () `resolves)
2. INSTALL: Success (logged when `appinstalled` event fired)

For more information, see Guidelines for writing bug reports
in MDN.

Bonus: add a screenshot or screencast of the issue

Although not required, in some cases it can be helpful to add a screenshot or screencast of the problem. This is especially useful in cases where the errors may require some strange steps to reproduce. Often times, it can be helpful to be able to see what is happening on a screencast or in a screenshot.

Include environmental details

Some errors are reproducible only on certain operating systems, or only on specific types of screens (for example, low or high dpi). Be sure to include the details of the test environments you used.

Submit the bug

Finally, submit the error. Then remember to keep an eye on your email for responses to the error. Typically, during the investigation and when correcting the error, the engineers may have additional questions or, if they have difficulty reproducing the problem, they may communicate.

R Marketing Digital