| 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. |
