Reporting and maintaining bugs for QtWebKit

Where to report bugs

Bugs are reported together with other ports on WebKit Bugzilla. Please use the template shortcut ​http://webkit.org/new-qtwebkit-bug to make sure that your bug report appear in the appropriate filters. For more detailed information see the bug fields description.

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 provide more information about 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

Steps to reproduce a crash

Because crashes are often caused by complex conditions, it is usually difficult to provide a test case reproducing them. In that case:

• Try to reproduce the crash more than once. Describe as best as you can the steps required to reproduce it.
• If your can run a debug build of QtWebKit and attach a stack trace of the crash to the bug report, this would further help the investigation.
  Note: The debug builds of Qt do not include debugging information for QtWebKit by default to prevent linking problems. A debug build from trunk or a nightly package of QtWebKit is currently required to extract reliable stack traces.

Useful filters for QtWebKit bugs

• ​Untriaged bugs

• Triaged bugs
  • ​All
  • ​API
  • ​Compilation
  • ​Crashes
  • ​Enhancements
  • ​Rendering and Layout
  • ​Performance
  • ​Plugins
  • ​Tools and Tests

• Other
  • ​QtWebKit 2.1 Pending API

Triaging bugs

​Triaging bugs basically means sorting out the good bug reports from the bad ones. It's an important step for keeping the bug database clean and maintainable.

The following steps are used by the developers when triaging QtWebKit bugs:

1. Verify that the bug report has a test-case
   • If there's no test-case, close the bug as resolved INVALID with a comment asking for more info.
2. Try to reproduce the bug on your local system. Ideally you should only triage bugs that are reported against your local platform.
   • If the bug was reported against the same platform as your own, and you could not reproduce the bug in trunk, close the bug as resolved WORKSFORME with a comment.
   • If you cannot reproduce the bug, but your system is different than the reported one, add a comment to the bug but don't close it. It might be valid for the reported platform.
   • If the bug was reported against a platform but you could reproduce it on another platform, change the Platform and OS fields to reflect this.
3. Verify all the fields and update them if they are not accurate (in particular the Severity and Component fields)
4. Set a priority for the bug
   • P1 means the bug should ideally be fixed for the next release (typically crashes or other serious bugs)
   • P2 means the bug is important, but not critical for a release like P1s are
   • P3 means the bug is valid, but due to limited resources in the QtWebKit team it is considered after P1s and P2s. If a P3 bug is important to you, see the QtWebKit ​contribution guidelines on how to help getting it fixed.
5. If the status is UNCONFIRMED, set it to NEW.
6. Change the assignee from ​webkit-unassigned@webkit.org to ​webkit-qt-unassigned@trolltech.com. This marks the bug as triaged, and will notify people who are watching the list of triaged bugs.

Bug fields description

Component

The ​component is used to signify the rough area 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 only be used for bugs/features in the public 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.

Summary

Choose a descriptive summary/title for the bug and prefix the summary with "[Qt]" if the bug only applies to the Qt-port.

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.