Information Gift

Debugging on Safari

Much of this will come as old news to Mac web developers, but those who work primarily on WinOS may benefit from the following Safari debugging tips.

Like Internet Explorer on Windows, Safari has come pre-installed on every Mac for a few years now, and as a result, can be considered the most commonly used browser on that platform. While Safari boasts some of the best standards support out there, DOM manipulations can be a bit finicky. Further, the browser itself is optimized for the general user, and, at first glance, doesn't have some of the features professional web developers rely upon for debugging problems.

However, underneath-the-hood utilities and free third party additions show developer love that make debugging the platform much easier.

One unique Safari feature that is useful to developers is the Activity Window. This window shows your page objects in a collapsible list view. Double-clicking an object listing opens that object in a new browser window; option-clicking downloads it. The list shows object file sizes and is updated in real-time. I often use this as a diagnostic tool and shortcut to access scripts, css and swf files for testing and version checking.

The Hidden Debug Menu:
As it happens, Safari comes with a set of debugging tools that are hidden by default. Most of the tools are useful only to Safari and WebKit engineers, but a few will come in handy for us once we can access the menu. Enable the Debug menu by opening the Terminal and entering the following string, hitting return and then restarting Safari:

defaults write com.apple.Safari IncludeDebugMenu 1

This adds a line to Safari's preference file; on next launch Safari will expose the Debug Menu to the right of the Help Menu.

If the Terminal makes you a bit uncomfortable, Safari Enhancer is a free util that enables the Debug menu, along with other customizations you might find useful or amusing.

Items in the Debug menu useful to web developers and testers include logging and showing Javascript errors, switching user agents, and possibly, Page Load Testing. Double-clicking on an an entry in the error console will open to the offending line in your source view.

Third party additions:
Speaking of source view, I also use Kasper Nauwelaerts' free Safari Tidy plug-in, which automatically validates pages, adding an icon and error/warning/success info to your status bar, line numbers and an error/warning view to your source window. Clicking on the status bar icon opens your source view and double-clicking on an error or warning takes you to the line in question.

Les Nie's Safari WebDevAdditions adds a slew of options similar to Chris Pederick's well-known Web Developer Extension for Firefox. Besides the usual show/hide/outline objects, you can view image dimensions, make the entire page editable, and employ an interactive Javascript console.

Apple resources:
Safari is in constant development via the WebKit Open Source Project; many dhtml bugs continue to be identified and addressed in WebKit, with Safari benefiting with each version upgrade. WebKit nightly builds are available, and while WebKit should not be used for general testing, it can be useful for reality-checking problems you suspect lie in Safari instead of your code. Should you find a bug that renders properly in a WebKit nightly but fails in the latest Safari, you might save valuable debugging time and move to a different approach that does work in Safari.

WebKit also includes a nod to web developers with Drosera, a Javascript debugger, and the Web Inspector, which "allows you to view the live DOM hierarchy in a compact HUD style window" and is very, very cool. I suspect we'll see both of these tools in the next official Safari release, but we will probably have to wait for Leopard, reportedly due in Spring.

Lastly, Apple's Safari Developer Connection has a FAQ that may answer some of your support questions.