Javascript Logging via Meta
January 10, 2005
Sometimes, it is the simplest ideas that we programmers always seem to overlook. I cannot count the number of times I have typed some variant of a javascript alert message to debug some pesky event handler or form validator. Often times, I attempt to run the script before fully understanding the execution path of the debugging code I entered. As a result, I send the javascript engine into an infinite loop of alerts, forcing me to have to issue an xkill on the browser.
During my late nights burning the midnight oil with javascript, I have come up with various ways to stuff debug messages into the output, such as in the statusbar, the document title, appending to the DOM and of course the infamous alert message. However, each of these methods have issues and are far from an ideal solution.
What I needed was a consistent, lightweight way to trace the javascript execution paths. Finally, while driving to work, it came to me. All this time I have only considered appending to the body of DOM, but never the head. As soon as I looked up towards the head of the document, the answered seemed to practically fall on me. Since Mozilla has an embedded viewer for reading the content of a document's META tags, I recognized that I could simply write a log function that uses the DOM to add a new META tag entry for each statement, suffixing the name attribute with the current line number.
<meta
name="X-jslog:1"
content="Hello World! This is your friendly logging service." />
To view the messages, I can simply go to "View > Page Info" and browse the entries in the Meta section. It almost seems too perfect. The only issue is that Mozilla does not dynamically update this list, so it is necessary to close and reopen the Page Info dialog.
I have added the Logger script to the script sandbox page of my wiki, which describes how to configure and use this micro logging framework. I hope you find this to be useful in the wee hours of the night and relish never having to xkill your browser again because of an infinite alert loop. Enjoy!
6 Comments from the Peanut Gallery
1 | Posted by Ed Chang on February 18, 2005 at 05:59 AM EST
Interesting way to debug. However, take look at http://www.mozilla.org/docs/web-developer/js/debugging/index.html for Mozilla's tips on JS debugging. Here's a few from the list:
* strict code checking If you set the pref "javascript.options.strict" to true, the JavaScript engine gives you more types of warnings on the JavaScript console, most of which hint at code bugs that are easy to oversee or even bad syntax.
* dump() Allows you to print text on the native console. Use \n to output a newline at the end. To see anything, you need to set the pref "browser.dom.window.dump.enabled" to true, e.g. in ; and to have a native console at all under MS Windows, you need to start Mozilla via mozilla.exe -console. Using normal JS object inspection, you can write a function that dumps a whole object, similar to this ddumpObject().
* Call stack You can print the current call stack (which functions were called to reach the current point) using the keyword debugger.
2 | Posted by Stephan Strittmatter on November 11, 2005 at 05:36 AM EST
Inspired of your blog entry, I created an appender for my log4js library.
3 | Posted by Dan Allen on November 16, 2005 at 09:53 AM EST
Alright! Getting some love from the AJAXian world!
I actually used my meta-logging recently to do some debugging for a javascript highlighting tool that I am implementing for my company's web application. It was very helpful. The only problem is that Firefox doesn't dynamically update the meta information panel (guess they never imagined that it would be used in this way), so it is necessary to keep closing and opening it.
Understand that I was inspired to write this library after growing frustration with browser lockups do to infinite loops of dialog popups blocking my control over the main window (and because the status bar sucks for logging). It is my opinion that the modal dialog window for alerts is inappropriate for this very reason. Either way, it is much easier to see event logging via a background queue.
4 | Posted by Stephan Strittmatter on December 09, 2005 at 05:36 AM EST
Log4js is now hosted as official project at http://log4js.berlios.de. There I also added - beside of the MetaAppender - also an AjaxAppender to send the logs via XMLHttpRequest to the server back, where the logs are taken by log4j (or whatever you want else) to store them.
5 | Posted by Dan Allen on December 13, 2005 at 02:04 AM EST
Great work Stephan! It's interesting that you mention the AjaxAppender mode because a couple of years back (before AJAX had a name), I implemented an error notifier called jsError using XMLHttpRequest and a server side PHP script to write all javascript errors to a server log.
Javascript errors are helpful while developing, but are silently ignored in production since they are sent to the user, rather than the logs. This little program works around that issue.
There is no reason why this concept couldn't be integrated right into log4js.
6 | Posted by Stpehan Strittmatter on December 14, 2005 at 04:13 AM EST
Thanks Dan,
I thought I was the first having this idea, but learnd now, that it is an old already invented wheel :-/
The AjaxAppender is already ready in log4js you can get it from Subversion. This appender is flexible to have an attached url to be called in XMLHttpRequest and the loggingEvent is passed as XML to this url and can be processed individual then.
I am not familar with PHP, but probably you could provide us a modified script of yours PHP and I will inegrate it as example.