嗓子有痰是什么原因

百度 品效合一彰显不可替代的凤凰影响发端于香港的凤凰卫视是使命是把全球华人距离拉近,成为华语电视节目提供商的领导者；今年凤凰卫视已经连续14年蝉联《中国500最具价值品牌排行榜》。

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

   Versions of WebKit that are not part of a Safari release have a + after the version number, and their version number is generally higher then the latest released version of WebKit. So, for example, 528+ is an unofficial build of WebKit that is newer than the 525.x version that shipped as part of Safari 3.1.2.

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. If you’re running on OS X this would often be platform Macintosh and OS Mac OS X 10.5 (Leopard). If you’re running on Windows or Linux, please select PC for platform and the appropriate entry from the OS field. If your exact system is not listed, please select the closest entry and provide further details in the description of the bug report.

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:

   • Include the domain of the page that shows the bug (especially if it’s an important site)
   • If the bug is a crash, note this and note whether or not the crash is reproducible
   • If you have tested and verified that this is a regression from a previous version of WebKit, prepend “REGRESSION: ” to the summary
   • If you know the range of revisions in which the regression occurred, add this to the summary after REGRESSION (i.e., “REGRESSION(r31201-r31211):”)
8. Description

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

   Tips for Descriptions:

   • Do not include more than one bug in one bug report.
   • If you built WebKit yourself or used a WebKit Build Archive, include the SVN revision number as well as information about if you are using WebKit with Qt, GTK+, wxWidgets, etc.
   • If loading a single URL is not enough to show the bug (for instance, you have to click through multiple pages for the bug to occur), then describe the exact navigation required to reach the page where the bug occurs. Don’t just say “go to the forums”; use detailed steps.
   • Look at the system console and include any messages that might be relevant in the bug.
   • Include the backtrace if you get a crash, if possible. File the bug first and then add the backtrace as an attachment.
   • Include a screenshot for visual bugs. If the problem isn’t very obvious, include a single screenshot which shows both correct and incorrect renderings, for example Safari and another browser such as Firefox or Internet Explorer. On the Mac you can use Grab.app or Cmd-Shift-4 and capture a snap that demonstrates the problem. You can then attach the screenshot to the bug.
   • Be as specific as possible. For instance, if you’re describing a problem that occurs while scrolling, note in the bug whether you’re scrolling with arrow keys, arrow buttons, scroll thumb, clicking above or below the thumb, scroll-wheel mouse, etc.
9. Keywords

   If the bug is specific to one or more of the ports of WebKit (Mac, iOS, GTK, EFL, Windows), please use any of the valid keywords to tag the bug report accordingly.

10. Depends on

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

11. Blocks

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