Bug Report Guidelines

This document describes how to write a good WebKit bug report. Good bug reports help developers and quality assurance (QA) people decide an appropriate priority and severity for a bug, and increase the chance that a bug will be fixed quickly. The more specific information you can provide, the better.

  1. Version

    Please select the WebKit version you were using when the bug occurred, or the closest match. 312 is the WebKit version that shipped with Mac OS X 10.3.9. 412 up to 418.8 are the WebKit versions that shipped with Mac OS X 10.4 (Tiger) and it's updates.

    Locally-built versions of WebKit have a + after the build number, and their build number is generally higher then the latest release version. So, for example, 420+ is a locally-built version of WebKit that's newer than the 418.8 version that shipped with the latest update of Tiger.

  2. Component

    If you know the precise cause of a bug (i.e., you've reduced it to a failing test case and know the reason), then you can assign a bug to a specific component such as CSS or HTML Editing.

    If, however, there is any doubt in your mind as to the cause of the bug, then file it under New Bugs. This component is the place for any bugs whose cause has not yet been determined. Once someone has reduced the bug and knows the cause, then it will be moved from the New Bugs component to the appropriate place.

  3. Platform and OS

    Please select the platform and the OS version that your bug occurred on. Typically this would be platform Macintosh and OS Mac OS X 10.3 (Panther) or Mac OS X 10.4 (Tiger).

  4. Priority

    Normally a QA person or developer will set this, so the bug submitter can leave this at the default value. A number of guidelines and some individual judgment are involved in setting the priority. If you know the bug is a regression, ie. something is wrong which wasn't wrong in previous versions of WebKit, you can set this to P1.

  5. Severity

    In most cases you should leave this at normal, but if you are confident that your bug is trivial or an enhancement, it's helpful to specify that value. A QA person or developer will set this to some other value if appropriate.

  6. URL

    Fill in this field with the URL of a page that shows the bug, when possible. If you have created a test case reduction for the bug, please add it to the bug report as an attachment rather than putting it on a web server and listing its URL here. Doing so makes it easier to work on the bug, and can be a first step towards checking in the test case along with the bug fix.

  7. Summary

    A good summary explains the problem in clear and specific terms, but is often concise enough to fit within the default summary space in Bugzilla. One should be able to tell exactly what a bug is about just by reading the summary.

    Tips for a good summary:
  8. Description

    In this field, write a more detailed explanation of the problem.

    Tips for Descriptions:
  9. Depends on

    If the fix for this bug depends on another bug fix, put the other bug's number here. Otherwise, leave it empty.

  10. Blocks

    If this bug blocks another bug from being fixed, put the other bug's number here. Otherwise, leave it empty.