Please note, this is a STATIC archive of website developer.mozilla.org from November 2016, cach3.com does not collect or store any user information, there is no "phishing" involved.

主控台訊息

正在翻譯中。

訊息顯示窗格佔據了網頁主控台的大部分:

每個訊息都會以單獨的行顯示出來:

Time(時間) 訊息被紀錄的時間。預設情況並不顯示:你可以在工具箱內設定讓時間戳出現。
Category(類別)

類別:它標示這訊息屬於什麼類別:

  • 黑色:網路請求
  • 藍色:CSS 警告/錯誤/日誌
  • 橘色:JavaScript 警告/錯誤
  • 紅色:安全性警告/錯誤
  • 綠色:伺服器日誌
  • 淺灰色Console API 訊息
  • 暗灰色:與命令行解釋器互動的輸入/輸出
Type(種類) For all messages except network requests and interactive input/output an icon indicating whether it is an error(X), a warning(!) or an informational log message (i).
Message(訊息) 訊息本身。
Number of occurrences(出現次數) 若該行產生的警告或錯誤被執行一次以上,該行只會紀錄一次、並用計數器表明被執行多少次。
Filename and line number(文件名和行數)

對 JavaScript、CSS 與主控台的 API 訊息而言,訊息可以追蹤到特定的程式碼行數。主控台接著會提供一個能鏈接到生成該訊息的文件名和行數。

從 Firefox 36 開始,還會提供訊息生成的列數。

By default, the console is cleared each time you navigate to a new page or reload the current page. To override this behavior, check "Enable persistent logs" in the Settings.

Message categories

Network

Network log messages are not shown by default. Use the filtering feature to show them.

Network requests are logged with a line that looks like this:

Time The time the message was recorded.
Category Indicates that the message is an HTTP request.
Method

The specific HTTP request method.

If the request was made as an XMLHttpRequest, there's an additional note indicating this:

URI The target URI.
Summary The HTTP version, status code, and time taken to complete.

Viewing network request details

If you click on the message, you'll be redirected to the Network panel where the request is selected and more request and response details are shown within the side panel at the right side. In versions prior to Firefox 43 this information was shown in a separate popup.

Starting in Firefox 48, you can access much of this detail inline, without leaving the Web Console. Network request entries get a disclosure arrow next to them. Click this to see:

  • Headers: request and response headers
  • Response: the response body
  • Cookies: any cookies that were sent along with the request
  • Call Stack (new in Firefox 50): for requests initiated by JavaScript, such as XMLHttpRequest or Fetch, you can see the call stack at the point the request was made.

JS

JavaScript messages look like this:

New in Firefox 49

JavaScript errors contain a "Learn more" link that takes you to the JavaScript error reference containing additional advice for fixing issues:

Source maps

New in Firefox 50 (but disabled by default)

From Firefox 50, the Web Console understands source maps. This means that if your JavaScript sources are compressed, you can supply a source map for them. Then any messages or errors your source generates will show up in the Web Console with a link back to the original source, not the compressed version.

At the moment source map support is disabled by default. To enable it, visit "about:config", find the preference "devtools.sourcemap.locations.enabled" and set it to true.

Be aware that support is still experimental. It may have bugs and may slow down console output. Bug 1289570 tracks any work that needs to be done before source map support can be enabled by default.

CSS

CSS warnings and reflow messages are not shown by default. Use the filtering feature to show them.

CSS messages look like this:

Reflow events

The Web Console also logs reflow events under the CSS category. A reflow is the name given to the operation in which the browser calculates the layout of all or part of the page. Reflows occur when a change has happened to a page that the browser thinks affects the layout. Many events can trigger reflows, including: resizing the browser window, activating pseudoclasses like :hover, or manipulating the DOM in JavaScript.

Because reflows can be computationally expensive and directly affect the user interface, they can have a big impact on the responsiveness of a website or web app. By logging reflow events the Web Console can give you insight into when reflow events are being triggered, how long they take to execute and, if the reflows are synchronous reflows triggered from JavaScript, which code triggered them.

Reflow events are logged as "Reflow" messages, as distinct from CSS errors or warnings. By default, they are disabled. You can enable them by clicking the "CSS" button in the toolbar and selecting "Reflows".

Each message is labeled "reflow" and shows the time taken to execute the reflow:

If the reflow is a synchronous reflow triggered from JavaScript, it also shows a link to the line of code that triggered the reflow:

Click the link to open the file in the Debugger.

Synchronous and asynchronous reflows

If a change is made that invalidates the current layout - for example, the browser window is resized or some JavaScript modifies an element's CSS - the layout is not recalculated immediately. Instead, the reflow happens asynchronously, the next time the browser decides it needs to be done (generally, the next time the browser repaints). In this way the browser can save up a collection of invalidating changes and recalculate their effect at once.

However, if some JavaScript code reads a style that has been modified, then the browser must perform a synchronous reflow in order to calculate the computed style to return. For example, code like this will cause an immediate, synchronous, reflow, when it calls window.getComputedStyle(thing).height:

var thing = document.getElementById("the-thing");
thing.style.display = "inline-block";
var thingHeight = window.getComputedStyle(thing).height;

Because of this, it's a good idea to avoid interleaving write and read calls to an element's styles when manipulating the DOM, because every time you read back a style that has been invalidated by a previous write call, you force a synchronous reflow.

Security

Security warnings and errors look like this:

The security messages shown in the Web Console help developers find potential or actual vulnerabilities in their sites. Additionally, many of these messages help educate developers because they end with a “Learn More” link that takes you to a page with background information and advice for mitigating the issue.

The complete list of security messages is as follows:

Message Details
Blocked loading mixed active content The page contained mixed active content: that is, the main page was served over HTTPS, but asked the browser to load "active content", such as scripts, over HTTP. The browser blocked this active content. See Mixed Content for more details.
Blocked loading mixed display content The page contained mixed display content: that is, the main page was served over HTTPS, but asked the browser to load "display content", such as images, over HTTP. The browser blocked this display content. See Mixed Content for more details.
Loading mixed (insecure) active content on a secure page The page contained mixed active content: that is, the main page was served over HTTPS, but asked the browser to load "active content", such as scripts, over HTTP. The browser loaded this active content. See Mixed Content for more details.
Loading mixed (insecure) display content on a secure page The page contained mixed display content: that is, the main page was served over HTTPS, but asked the browser to load "display content", such as images, over HTTP. The browser loaded this display content. See Mixed Content for more details.
This site specified both an X-Content-Security-Policy/Report-Only header and a Content-Security-Policy/Report-Only header. The X-Content-Security-Policy/Report-Only header(s) will be ignored. See Content Security Policy for more details.
The X-Content-Security-Policy and X-Content-Security-Report-Only headers will be deprecated in the future. Please use the Content-Security-Policy and Content-Security-Report-Only headers with CSP spec compliant syntax instead. See Content Security Policy for more details.
Password fields present on an insecure (https://) page. This is a security risk that allows user login credentials to be stolen. Pages containing login forms must be served over HTTPS, not HTTP.
Password fields present in a form with an insecure (https://) form action. This is a security risk that allows user login credentials to be stolen. Forms containing password fields must submit them over HTTPS, not HTTP.
Password fields present on an insecure (https://) iframe. This is a security risk that allows user login credentials to be stolen. iframes containing login forms must be served over HTTPS, not HTTP.
The site specified an invalid Strict-Transport-Security header. See HTTP Strict Transport Security for more details.

This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1.

The site uses a certificate whose signature uses the SHA-1 hash algorithm.

SHA-1 is still still widely used in certificates, but it is starting to show its age. Web sites and Certification Authorities are encouraged to switch to stronger hash algorithms in future. See the Weak Signature Algorithm article for more details.

Note that the SHA-1 certificate may not be your site's own certificate, but may be the certificate belonging to a Certification Authority that was used to sign your site's certificate.

Bug 863874 is the meta-bug for logging relevant security messages to the Web Console. If you have more ideas for useful features like the ones discussed here, or are interested in contributing, check out the metabug and its dependencies.

Logging

Messages logged from Shared Workers, Service Workers, add-ons, and Chrome Workers are not shown by default. Use the filtering feature to show them.

The Logging category includes messages logged using the Console API.

The Web console supports the following Console API messages:

The console prints a stack trace for all error messages, like this:

function foo() {
  console.error("it explodes");
}

function bar() {
  foo();
}

function doStuff() {
 bar();
}

doStuff();

Server

New in Firefox 43

Server-side log messages are not shown by default. Use the filtering feature to show them.

From Firefox 43, the Web Console can display messages sent from the server. This enables you to use the Web Console to debug server-side code.

It uses the Chrome Logger protocol. Briefly, the way it works is:

  • your server-side code - Python, PHP, Node.js, ... - includes a library that provides a console API
  • your server-side code uses this API to log messages
  • the server-side library creates JSON objects from the messages and encodes them for transmission
  • the messages are transmitted to the client as a response header named X-ChromeLogger-Data
  • the Web Console decodes these headers and displays them

To find a suitable library for your server code, see the Chrome Logger documentation.

Command line input/output

Commands sent to the browser using the Web Console's command line, and the corresponding responses, are logged using lines like this:

The dark gray bar indicates that these are input/output messages, while the direction of the arrow discriminates between input and output.

Filtering and searching

Filtering by category

You can use the toolbar along the top to constrain the results displayed.

To see only messages of particular categories, click the button labeled with that category ("Net", "CSS", and so on). Clicking the main part of the button toggles that category on or off, while clicking the arrow on the right gives you more fine-grained filter options within that category:

  • Net
    • Errors
    • Warnings
    • XHR
    • Log
  • CSS
    • Errors
    • Warnings
    • Reflows
  • JS
    • Errors
    • Warnings
  • Security
    • Errors
    • Warnings
  • Logging
    • Errors
    • Warnings
    • Info
    • Log
    • Shared Workers
    • Service Workers
    • Add-on or Chrome Workers
  • Server
    • Errors
    • Warnings
    • info
    • Log

用文字過濾

To see only messages that contain a specific string, type in the text box labeled "Filter output".

清除日誌

>最後,您可以使用工具欄清除日誌。在 Firefox 48 以前,可以按下右邊的「清除」按鈕。在 Firefox 48 以後,可以按下左邊的垃圾桶圖示。

文件標籤與貢獻者

 此頁面的貢獻者: iigmir
 最近更新: iigmir,