mozilla

Revision 93854 of Console service

  • Revision slug: Console_service
  • Revision title: Console service
  • Revision id: 93854
  • Created:
  • Creator: Jorend
  • Is current revision? No
  • Comment /* Logging Messages */

Revision Content

The Console Service interface supports logging runtime messages from any source. Messages can then be displayed to the user with the JavaScript Console, logged to disk, etc.

Logging Messages

The console service should be used to log any message that might be of concern to a user or UI/component developer. The console service currently gets messages from XUL and content JavaScript, XPI JavaScript, and JS Components. Other candidates are Prefs, the XML parser and XPConnect. I intend for the error list to be filterable from the JavaScript UI, so be promiscuous with what you log.

To log a message, call LogStringMessage on the service. If you want to associate more information than just a string with your message, make an XPCOM object that's QIable to nsIConsoleMessage and call LogMessage - JavaScript errors currently log instances of nsIScriptError. Console listeners can then attempt to QI from nsIConsoleMessage to richer message types that they know about. An example of logging a message is the JavaScript Component loader.

Thread safety

The console service is intended to be thread-safe; you should be able to log messages to the service from any thread. Listeners registered with the service are proxied when they are registered. When a new message is logged, each listener will be notified (asynchronously) on the thread from which it was originally registered. (For this reason, each listener must be registered on a thread with an event queue.)

Retiring Old Messages

In order to prevent denial of service by a page that generates an unbounded number of errors, the console service maintains a LIFO circular buffer of messages, and begins retiring old messages once the message limit is reached.

The JavaScript Console

One client of the console service is the JavaScript Console. (tasks->tools->JavaScript Console) The JavaScript Console polls the console service for messages that have been logged so far, and registers itself with the service as a listener for new messages. The console service itself doesn't depend on JavaScript. Everything in the console service is scriptable, and the JavaScript Console window is implemented in pure XUL/js.

Thanks to Martijn Pieters, we have a command line handler for the js console. To start up with the js console, use the '-jsconsole' argument.


Mike McCabe

Revision Source

<p>The <a class="external" href="http://lxr.mozilla.org/seamonkey/source/xpcom/base/nsIConsoleService.idl">Console Service interface</a> supports logging runtime messages from any source. Messages can then be displayed to the user with the JavaScript Console, logged to disk, etc.
</p>
<h3 name="Logging_Messages"> Logging Messages </h3>
<p>The console service should be used to log any message that might be of concern to a user or UI/component developer. The console service currently gets messages from XUL and content JavaScript, XPI JavaScript, and JS Components. Other candidates are Prefs, the XML parser and XPConnect. I intend for the error list to be filterable from the JavaScript UI, so be promiscuous with what you log.
</p><p>To log a message, call LogStringMessage on the service. If you want to associate more information than just a string with your message, make an XPCOM object that's QIable to <a class="external" href="http://lxr.mozilla.org/seamonkey/source/xpcom/base/nsIConsoleMessage.idl">nsIConsoleMessage</a> and call LogMessage - JavaScript errors currently log instances of <a class="external" href="http://lxr.mozilla.org/seamonkey/source/js/src/xpconnect/idl/nsIScriptError.idl">nsIScriptError</a>. Console listeners can then attempt to QI from nsIConsoleMessage to richer message types that they know about. An example of logging a message is the <a class="external" href="http://lxr.mozilla.org/seamonkey/source/js/src/xpconnect/loader/mozJSComponentLoader.cpp#197">JavaScript Component loader</a>.
</p>
<h3 name="Thread_safety"> Thread safety </h3>
<p>The console service is intended to be thread-safe; you should be able to log messages to the service from any thread. Listeners registered with the service are proxied when they are registered. When a new message is logged, each listener will be notified (asynchronously) on the thread from which it was originally registered. (For this reason, each listener must be registered on a thread with an event queue.)
</p>
<h3 name="Retiring_Old_Messages"> Retiring Old Messages </h3>
<p>In order to prevent denial of service by a page that generates an unbounded number of errors, the console service maintains a LIFO circular buffer of messages, and begins retiring old messages once the message limit is reached.
</p>
<h3 name="The_JavaScript_Console"> The JavaScript Console </h3>
<p>One client of the console service is the JavaScript Console. (tasks-&gt;tools-&gt;JavaScript Console) The JavaScript Console polls the console service for messages that have been logged so far, and registers itself with the service as a listener for new messages. The console service itself doesn't depend on JavaScript. Everything in the console service is scriptable, and the JavaScript Console window is implemented in pure XUL/js.
</p><p>Thanks to <a class="external" href="mailto:mj@digicool.com">Martijn Pieters</a>, we have a command line handler for the js console. To start up with the js console, use the '-jsconsole' argument.
</p><p><br>
</p><p><i><a class="external" href="mailto:mike+mozilla@meer.net">Mike McCabe</a></i>
</p>
Revert to this revision