Safari, Firefox wildly crashing

Image via CrunchBaseA few weeks ago I had huge problems with stability of my web browsers - at first it started with Firefox and although at first it was limited to it alone I quickly realized that I was wrong and that Safari just as happily crashes as Firefox. Since this was the first time I had any real stability issues since I switched to Mac I decided to take a bit more thorough look at how crash reporting is conducted on Mac.

(For a solution to why Firefox and Safari crashed as often as they did, you can skip to the end of article.)

Partial problem that prevented any useful debugging with Firefox was that Mozilla crash reporter only gives you a text area field to tell them what you did before the browser crashed. I was later informed by Brian King that Mozilla gets a lot more information than it shows to user and discovered this little gem - Mozilla Crash Reporter - basically, one can type about:crashes to get a list of links to crash reports as they were submited to Firefox developers or, if that is not an option (you're either offline or your Firefox crashes at start), look into ~/Library/Application Support/Firefox/Crash Reports/.

Few days after Firefox, Safari started crashing. If for Firefox I at first speculated that browser crashes when I visit secure web pages (it constantly crashed at Firefox Add-on page and at my banking site), this time I couldn't establish any meaningful pattern.

But Safari does show you Apples default Crash Reporter which gives you a lot more information by default and now I had to get down and dirty with the problem since browsing the web was no longer possible. After a bit of staring at the Crash Reporter log output I posted a thread at Apples Discussion forum and started to dig around for documentation related to Crash Reporter.

Luckily, the response at discussion board was almost instant (as said, solution below), but I still decided to get a bit more knowledge about Crash Reporter and managed to find Apples Technical Note TN2123 that gives deep insight about what is what and where in the crash report - most of the information is important only to developers but when you are faced with a problem similar to mine, this can just be your solution.

What I did notice is that its problem is not the lack of information, it is how these information ca be passed to third party developers - and this appears to be a rather long standing issue since it was discussed by John Gruber back in 2006 already and Apples recommendation is still the same.

After getting a bit more familiar with what Crash Reporter really wanted to say to me and still wondering what most of the services were, I was educated that the problem was with Apple Type Server, or ATS. As soon as this was mentioned I realized what the problem was all along - about two week back from when Safari started crashing I installed Windows fonts for some application.

At that time Font Book said that I have duplicate fonts and one corrupted one but I never imagined that those could cause any serious problems down the road so I moved along. Since I don't use Firefox daily and never quit Safari, fonts that browser used never got reloaded and only started causing problems when they were used on various web pages.

Removing duplicate and corrupted fonts resolved the issue for good.

"Apple Cripples Non-Apple Software"

Source: FlickrIt didn't come as no suprise to me when I first saw this sensationalistic title appear on Slashdot two days ago. But it was sad to see how a wonderful piece of work like that produced by Vladimir Vukićević in his blog post got distorted and taken out of context (or at least part of it) for the purpose of the argument.

As Vladimir was looking how to give Firefox 3 for OS X some performance boost he did quite some research and testing to locate origins of bottlenecks that made OS X version of Firefox a black sheep in the past - at least compared to it's Windows and Linux siblings.

During his research he discovered that Apple was using some undocumented methods to give Safari some boost in performance. Not realy a very nice thing to do for sure, yet he still emphesized that there are other non-programaticall ways for gaining the same boost. But the news of Apple's Evil had already began to spread in the wild and blow out of proportion.

Personally I think Apple was right this time not to publish this part of API - David Hyatt himself said that this code was more of a hack and they themself are not happy with that part of WebKit's code. As any developer knows publishing hacks is never a realy good idea - even using hacks is not a good idea but sometimes due to time constraints or some other reason you just have to use them.

One one side, using them can get you in such an awkward position as Apple has arguably found itself in, yet publishing information about them is still wrong - you lose the ability to fix the problems and remove hacks in the next release and are faced with maintaining them for a forseable future. Unless, of course, you want to be hated by developers using your API for making such (dramatic) changed over night.

But one is still left wondering if there are some other hidden and undiscovered cookies in Apple's jar. They are, after all, only a company and even if most of it's empoyees are open-source minded, there probably hides a genious or two in the dark corners of Apple that thinks otherwise and could destroy Apple's reputation on this matter and create a picture of another company with Microsoftish malpractice.