Reporting and maintaining bugs for QtWebKit

Where to report bugs

• ​The Qt bug tracker if you are a QtWebKit user
• ​http://bugs.webkit.org For in-release and auto-tests regressions, bugs that you intend to fix yourself or bugs that affect all ports of WebKit

​The Qt bug tracker can also be used to report suggestions or to track long term tasks. Project management is easier to do there.

Useful filters for QtWebKit bugs

• ​Untriaged bugs

• Triaged bugs
  • ​All
  • By platform
    • ​Windows
    • ​Mac
    • ​Linux
  • By topic
    • ​API
    • ​Compilation
    • ​Crashes
    • ​Enhancements
    • ​Rendering and Layout
    • ​Performance
    • ​Plugins
    • ​Tools and Tests
  • ​Meta bug to fix failing WK1 API tests
  • ​Meta bug to fix failing WK2 API tests
  • ​Meta bug to fix regressions cause layout test failures
  • ​Meta bug to fix crashes/assertions/timeouts
  • ​Meta bug to fix newly added but failing tests

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.

The table for the weekly bug triage task force (WTTF) is maintained in a separate wiki page: QtWebKitTriageRoster.

The Weekly Builds may be of help when trying to reproduce bugs on other platforms.

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.