Version 4 (modified by 15 years ago) ( diff ) | ,
---|
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
- Component filters
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
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.