Recently the long-anticipated Safari 4.0 was released. The earlier WebKit was already fast, but this version performs just insanely well. Reloading a page on your local host takes milliseconds as I showed in my last post. Even more importantly, Safari 4.0 comes with a new inspector which includes all the functionality of Firebug, although it’s still not quite as good as Firebug. It doesn’t have the error handling ability, especially for the in-memory Dojo JavaScript files that are initiated with XHR eval. I still use Firefox primarily for development, but I find myself using Safari more and more often, as I just can’t resist the almost instantaneous refreshing of the page.

If you’ve never used the Inspector in Safari before, you need to enable it. Go to Safari Preferences > Advanced, and check Show Develop menu in menu bar. You can then go to menu > Develop > Show Error Console.

Unfortunately, one of the detriments to Safari’s Inspector is its superfluous logging. Dojo applications in particular suffer from this problem. Here’s a screen shot of the Inspector with a Dojo test file loaded:

Safari Logs

This shows on every single file load. Okay, I get it. The JavaScript files are loading as text and the XHR has finished loading. This is like the Copyright Warning and superfluous logos at the beginning of every DVD you watch and can’t skip — Really, I get it!

This isn’t nitpicking, this is a big deal. As my friend Revin says my eyesight is precious. A little more scientifically, I read an article on the reason rounded corners are more pleasing to the eye than square corners. Studies show that square corners involve a different brain process that actually requires more work. Similarly, the Inspector continually showing me these messages is interrupting my thought process while I’m coding and trying to get into the zone.

It would be nice if you could turn this functionality off, but the Inspector has no preferences panel. It took a little while to figure out, but I have managed to make the Inspector bend to my whim.

Find the Files

The Inspector is built with HTML, JavaScript and CSS, so it’s actually very editable. Finding the files however, is the biggest trick. It turns out that Safari will tell you exactly where these files are with a right click. Open the Inspector and right click on any of the logs, which are actually HTML elements:

Safari Menu

This will open a second Inspector. This Inspector is the inspector for the first Inspector (I said that three times fast — it’s not hard). This is not valuable in itself, except for the path in title bar:

Safari New Debug

This is where the files are located. On my Mac, the path is:

/System/Library/Frameworks/WebKit.framework/Versions/A/Frameworks/WebCore.framework/Versions/A/Resources/inspector

Editing the Files

It took a long time to figure out where to make the edits. Ironically it was difficult to inspect the Inspector because this code interfaces with WebKit’s Objective-C code, not the browser window. You can’t use alerts, and logging is difficult since you are in a logger and it tends to want to log your logs which can cause infinite loops. Through experimentation, I managed to find where to choke off the mime-type warning messages. This is in Resource.js, line 540:

_checkWarnings: function()
{
	return; // <----- added this line
	for (var warning in WebInspector.Warnings)
		this._checkWarning(WebInspector.Warnings[warning]);
}

Note: Line numbers are approximate depending on your exact version.

I nullified this function by inserting a return at the beginning.

Next, I eradicated the XHR is loaded... messages. This was really tricky, because while the new message constructor, WebInspector.ConsoleMessage, is right there in Console.js line 575, it's never initiated in the JavaScript — it happens in the Objective-C code. After some painstaking logging of a message object, I found that its structure looks like this:

_format: function (parameters) { ... }
formattedMessage: HTMLElement
groupLevel: 0
isEqual: function (msg, disreguardGroup) {
isErrorOrWarning: function () { ... }
level: 1
line: 0
message: "XHR finished loading: 'http:test.local'"
repeatCount: 1
source: 3
toMessageElement: function () { ... }
toString: function () { ... }
url: ""

So while I couldn't prevent the message object from being created, knowing its structure allows me to prevent it from being inserted. New messages are added in Console.js, line 142. I inspect the msg.message, and block it if it contains the irritating message:

addMessage: function(msg)
{
	if(msg.message.indexOf("XHR finished loading")>-1){
		return;
	}

We've successfully cleaned up the Console panel! All the logs are now our own.

Bonus Styling Section

There are a few easy parameters you can change. In Preferences.js, on line 30 there is a Preferences object. Any of these parameters can be changed, but the two I have found most useful are:

  • minConsoleHeight which allows you to shrink the HTML section above so you can see more logs
  • minElementsSidebarWidth, which allows you to expand the HTML section to the right and shrink the Styles section so you can see more of the HTML

This is more clearly shown in the following picture:

Safari Move

And finally, font size. I gave a presentation on this topic, and the font size used in the Console panel does not display well on the big screen. Of course you may just prefer a different font size or style. At the end of inspector.css I added the following style definition, which resulted in the image that follows:

body, #console-messages{
	font-size:18px;
}

Safari Font Size

Automating the Process

There's one problem with all the suggestions above. When there is a Safari update, it will wipe out all of your changes. This has happened to me three times since Safari was released in early July. I would expect there would be fewer updates from here out, but this is still somewhat of a deterrent to using these customizations.

Robert Chady, my friend and colleague at SitePen, came to the rescue and wrote a shell script that automates the entire process. You can install this script and run it and not even have to bother with all of the information given above.

My shell scripting skills are mediocre at best, so I'm really glad I collaborated with Robert. Instead of doing string replacement on the files, he came up with a cleaner idea of applying a patch. He then took it even farther by allowing for parameters.

Download the Safari Inspector shell script

Note: This script was designed for use on a Mac since that is the majority of Safari users. It has not been tested on Linux. Windows users may feel free to make a BAT file using this as reference.

Shell Script Examples

After Safari is installed the permissions are set to not allow edits. You can get around this by using sudo. Also, after downloading the shell script you will need to apply the proper permissions so it will execute correctly:

chmod 755 squelch_inspector.sh

Without any parameters, the shell script will patch the JavaScript files to block the messages and change the height and width of the HTML and Style panels to 20 pixels.

sudo ./squelch_inspector.sh

By default the font size in the Console is not changed. To do so, supply an argument for the font size:

sudo ./squelch_inspector.sh -f 24

If you would like the panels to be a different size, or if the path to the files are different than the path shown here, there are additional options.

# -- Usage: squelch_inspector.sh
#	-f [#]		-- font size for inspector.css 
#				(default: 18px)
#	-F		-- patch the font size
#	-h [#]		-- height for Inspector
#	-p [path]	-- path to Safari Inspector
#	-w [#]		-- width for Inspector
#	-U		-- unpatch files

And if you don't like the changes or if you need to see the supressed messages, simply use the -U switch which will revert all of the files to their originals.

Conclusion

The Firebug Working Group has really done an excellent job on their product, with new features and bug fixes in every release. This is the Safari team's first effort, and they should be commended for a terrific first showing. The Safari team didn't work with Dojo like the Firebug Group did, so we do get side effects like too many messages and inaccurate error reporting. This shell script will help make the Safari Inspector more Dojo ready!