How to write a nice bug report


Reading through thisarticle gives you what is expected when you write a bug report.

When asking a question about a problem caused by your code, you will get much better answers if you provide code people can use to reproduce the problem. That code should be…

  • …Minimal – Use as little code as possible that still produces the same problem
  • …Complete – Provide all parts needed to reproduce the problem
  • …Verifiable – Test the code you’re about to provide to make sure it reproduces the problem

If your report does not fulfill those conditions, your report have to be “translated” by community moderators including me into something useful to find out if the bug is a new one, if it is consistently reproduced, etc., which often takes a lot of time.

Though every bug report is thankful, it is obvious that “the browser does not work” is not a good report. The ideal bug report is what you could forward it directly to the dev team; clear description, with necessary information, neither more nor less.

Here is a template you might want to use when you write a bug report.

### Description
[Description of the issue]

### Steps to Reproduce
Please add a series of steps to reproduce the problem. See for in depth information on how to create a minimal, complete, and verifiable example.


**Actual result:**
Please add screenshots if needed.

**Expected result:**

**Reproduces how often:**
What percentage of the time does it reproduce?

### Brave Version

**about:brave info:**
Please open about:brave, copy the version information, and paste it.

**Reproducible on current live release:**
Is this a problem with the live build? It matters for triage reasons.

### Additional Information
Any additional information, related issues, extra QA steps, configuration or data that might be necessary to reproduce the issue.

Videos/input problems
Youtube comments won't show up
Problems with link