Reporting and maintaining bugs for QtWebKit

Properties of a good bug report

To pass through triaging and get the chance to be fixed, a bug report should contain information allowing a developer to reproduce the problem quickly and easily on different versions without having to understand the problem first. If you can add more information to a bug that got closed as invalid, please re-open it.

Serious bug reporters might also want to have a look at the ​steps to report a bug and the ​reporting guidelines applying to the whole WebKit project.

Attached test case

Test cases are favored to external web site links since they are not vulnerable to external updates.

• For a page rendering bug, a minimal HTML file is usualy efficient.
• For bugs of more platform-related features, a zip file containing a C++ source file and a .pro file compilable by typing qmake && make might be required

Included stack trace for crashes

TODO

Useful filters for QtWebKit bugs

• Status filters
  • ​Bugs (unconfirmed or new)
  • ​Bugs (assigned)

• Component filters
  • ​API
  • ​Compilation
  • ​Crashes
  • ​Enhancements
  • ​Rendering and Layout
  • ​Performance
  • ​Plugins
  • ​Tools and Tests

• Other
  • ​QtWebKit 4.7 Pending API

Bug fields description

Component

The ​component is used to signify the rough are that the bug relates to.

If you don't know which one to choose leave the component at 'New Bug'. It's better to leave it at 'New Bug' than to choose one at random.

Note: the 'QtWebKit' component should be used for bugs/features in the QtWebKit API layer, not to signify that the bug is specific to the Qt port of WebKit (see Keywords]).

Severity

The ​severity is a signifier of what kind of bug we're talking about/how serious it is, and should not be confused with ​priority, ie, when it will/should be be fixed (see below).

Use the following rules of thumb when deciding on a severity:

• Use 'Blocker' for compilation errors/build breaks
• Use 'Critical' for crashes, loss of data, severe memory leak
• Use 'Enhancement' for feature-requests/enhancements

The severities 'Minor, Normal, Major' should then be used for "normal" bugs which don't fall into either of these categories, ranging from minor loss of function, or other problem where easy workaround is present, to major loss of function.

Platform and OS

Choose the settings most relevant to where you found the bug, or 'All' if you've confirmed that the bug exists on more than one platform.

Note: These two fields should not be used to signal which port of WebKit we're dealing with, but the underlying platform and OS.

Keywords

We need a way to track bugs that are specific for the Qt port of WebKit. The right way to do this is using the 'Qt' ​keyword (you may not see the keywords entry field until after creating the bug. If so, please add the keyword after creating the bug).

• Add the keyword 'Qt' to signal that it's a Qt-related bug
• Add the keyword 'Performance' if the bug is performance-related

Note: Do not use the 'QtWebKit' component to signal that it's a Qt bug. The QtWebKit component is used for bugs/features in the QtWebKit API layer, not to signify that the bug is a Qt-bug in general.

Version

Leave at 'nightly build'. You should always test a bug against a nightly build of QtWebKit to make sure that it's still valid before reporting.

Priority

This field is set by developers when scheduling and triaging tasks, please leave this at the default priority.