January 27, 2007
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.
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.
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.