8 | | === Useful filters for QtWebKit bugs === |
| 8 | == Properties of a good bug report == |
| 9 | 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. |
| 10 | If you can provide more information about a bug that got closed as invalid, please re-open it. |
| 11 | |
| 12 | Serious bug reporters might also want to have a look at the [http://webkit.org/quality/reporting.html steps to report a bug] and the [http://webkit.org/quality/bugwriting.html reporting guidelines] applying to the whole WebKit project. |
| 13 | |
| 14 | === Attached test case === |
| 15 | Test cases are favored to external web site links since they are not vulnerable to external updates. |
| 16 | * For a page rendering bug, a minimal HTML file is usualy efficient. |
| 17 | * 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 |
| 18 | |
| 19 | === Steps to reproduce a crash === |
| 20 | Because crashes are often caused by complex conditions, it is usually difficult to provide a test case reproducing them. In that case: |
| 21 | * Try to reproduce the crash more than once. Describe as best as you can the steps required to reproduce it. |
| 22 | * 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.[[BR]]'''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. |
| 23 | |
| 24 | == Useful filters for QtWebKit bugs == |
26 | | |
27 | | |
28 | | == Properties of a good bug report == |
29 | | 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. |
30 | | If you can provide more information about a bug that got closed as invalid, please re-open it. |
31 | | |
32 | | Serious bug reporters might also want to have a look at the [http://webkit.org/quality/reporting.html steps to report a bug] and the [http://webkit.org/quality/bugwriting.html reporting guidelines] applying to the whole WebKit project. |
33 | | |
34 | | === Attached test case === |
35 | | Test cases are favored to external web site links since they are not vulnerable to external updates. |
36 | | * For a page rendering bug, a minimal HTML file is usualy efficient. |
37 | | * 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 |
38 | | |
39 | | === Steps to reproduce a crash === |
40 | | Because crashes are often caused by complex conditions, it is usually difficult to provide a test case reproducing them. In that case: |
41 | | * Try to reproduce the crash more than once. Describe as best as you can the steps required to reproduce it. |
42 | | * 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.[[BR]]'''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. |