Safari and KHTML

Don Merton (formerly of and now engineering manager of Safari at Apple) has sent a message to the KDE developers explaining why Apple picked KHTML as the engine for their new Safari browser. He writes:

The number one goal for developing Safari was to create the fastest web browser on Mac OS X. When we were evaluating technologies over a year ago, KHTML and KJS stood out. Not only were they the basis of an excellent modern and standards compliant web browser, they were also less than 140,000 lines of code. The size of your code and ease of development within that code made it a better choice for us than other open source projects. Your clean design was also a plus. And the small size of your code is a significant reason for our winning startup performance….

Update: jwz claims that “translated through a de-weaselizer, this says:”

“Even though some of us used to work on Mozilla, we have to admit that the Mozilla code is a gigantic, bloated mess, not to mention slow, and with an internal API so flamboyantly baroque that frankly we can’t even comprehend where to begin. Also did we mention big and slow and incomprehensible?”

Apple releases web browser

Just caught the live feed from MacWorld 2003 where Steve Jobs demonstrated the new Apple web browser called Safari. Impressive. The SnapBack feature looks cool: You go to Google, search for something, go to one of the resulting sites and wander around a while, and then just click the SnapBack button to jump back in history to your original search results page. Seems a reasonable and frequently needed shortcut, although I’m unclear how it affects the back button and it might add some user confusion about which to use. He also demonstrated SnapBack with Amazon and said it worked for any site. I would have been really impressed if it worked for searches on any site, but I suspect it just goes to the root for non-known search engines. I liked the excellent mechanism for reporting bugs.

Jobs said it is based on the KHTML open source project when I expected it would be based on Gecko like Chimera. It really surprised me, especially after they hired David Hyatt. It remains to be seen how well Safari does with standards, but more standards-based browsers is a good thing. I hope it is solid. If Safari is really the fastest browser on the Mac, that’s cool.

I can’t wait to try it out.

Update: I added a link to the Safari information on the Apple website and to a KHTML page.

Community Bug Watching

I made some suggestions to Robert Wall about ways that he could improve his already quite nice Bonsai Bugs tool. As I mentioned earlier, I miss Asa’s informed and concise buildbar comments about what bugs are most interesting in each build.

Seeing Bonsai Bugs got me wondering if there was some way to determine the most interesting bugs without needing a human investigator. If Google’s shown us anything, it’s that you can use the power of the network to show you the most relevant information. What if Bonsai Bugs could somehow mark the bugs that have the most community interest and downplay those that are less important?

I came to the conclusion that there are several ways to evaluate community interest using data already in bugzilla. For example, the following criteria could be added together to devise a reasonable Community Interest Factor so that you could rank the bugs:

  • Bugs with many duplicates
  • Bugs with many votes
  • Bugs with a large list of CCs
  • Bugs with a large number of comments
  • Bugs with many dependencies (or even with a parent with many dependencies)
  • Bugs with certain keywords (for example, bugs fixed that have out of date milestones (Mozilla0.9), crash, dogfood, catfood, or 4xp keywords).
  • Joke: Bugs that I vote for or that I am CC’ed on.

Obviously these are somewhat vague and need to be tweaked to pick up those bugs that are most relevant. You could compare with the most frequently reported bugs list or recent duplicates list as well. You could search and see if a bug is a dependency of a “Make X release not suck” bug. I imagine you could even search Google or the newsgroups for each bug number and up the Community Interest Factor if you find additional links.

I’m happy to say that Robert found the idea a good one and we’ve had a stimulating discussion about ways to refine and improve this. You could be incredibly granular and show a great number of levels of community interest, but the result is that nothing really stands out. Five seemed like too many. I suggested to him that with the right threshold only two levels (normal and interesting) might be needed, but three felt about right (normal, interesting, and imporant).

I’m looking forward to the first release of the improved Bonsai Bugs. I imagine that the algorithms will continue to be refined and this will make it more enjoyable for the community to watch the tree grow.

Windows theme support

Interesting bug of the day: The fix for bug 172751 has been checked in. This should make Mozilla on Windows platforms other than XP look more like native apps. It fixes a few cosmetic glitches on XP as well. This will be most obvious with the Classic theme.

Enable/disable flash

A few days ago Blogzilla mentioned the jTFlashManager tool that lets you enable or disable flash on the fly. Investigating how the tool works shows that it just renames the plug-in file. I’ve been renaming the plug-in to disable it for a long time, but never tried doing this while the browser was running. For some reason I thought it read the plug-ins at startup.

The tool requires a Java VM to be installed and I thought that was overkill for renaming a file. I was a bit rusty, but wrote a DOS batch file that works beautifully as a shortcut from my Windows desktop. Save the toggleflash.bat file and then run it passing the path of your Phoenix, Mozilla, or Netscape plugin directory. If you’re not currently viewing a page using the flash or shockwave plug-ins, it will toggle them on or off.

Here’s the file:

@echo off
if "%1"=="" goto usage
if exist %1.\\npswf32.dll goto disable
if exist %1.\\ goto enable
echo Couldn't find a flash plugin.
goto usage

ren %1.\\npswf32.dll
if exist %1.\\np32dsw.dll ren %1.\\np32dsw.dll
echo Flash Disabled.
goto done

ren %1.\\ npswf32.dll
if exist %1.\\ ren %1.\\ np32dsw.dll
echo Flash Enabled.
goto done

echo You must specify the path to your browser's plugins directory.
echo Put the path in double quotes if it includes spaces.
echo For example, toggleflash.bat "c:\\Program Files\\Mozilla\\bin\\plugins"


Watch the tree grow

I was somewhat disappointed when Asa stopped updating the Build Bar over at MozillaZine. I enjoyed reading his summaries of the important bugs that had been fixed each day. This was especially helpful to me in testing nightly builds of Mozilla. Now with Mozilla 1.0 (and 1.1, and almost 1.2) shipped and the product generally quite stable, I’m not as concerned, but still miss the up to date news.

There are now a number of resources that help keep you equally or better informed about Mozilla development. The MozillaZine Mozilla Builds Forum and Phoenix Builds Forum provide a wealth of information.

Unfortunately, I most miss the short and to-the-point summaries that Asa provided, as well as his overall sense of the state of the project. One easy but verbose way to track Mozilla (and siblings) development is by watching CVS check-ins via Bonsai, which I’m sure it one of the tools Asa used. A day’s results from Bonsai provides more information than you’d probably want to wade through: it shows every file that was changed. Thankfully, several sites now condense the list of daily check-ins and cross-reference them with the relevant bugs. Bonsai Watch provided by MozillaNews gives the detailed bug information. I personally prefer the brief results provided by BonsaiBugs and BonsaiBugs for Phoenix from

Finally, there’s the weekly status update from, the previously mentioned news sites, and, and an ever increasing number of developers’ blogs.

Standards and contentEditable

Blogzilla characterizes the discussion in Mozilla bug 97284 as a war of Standards vs “But IE Does It”. They misunderstood the thinking behind my comments in that bug and missed what I believe is another point of view. Here’s a hint that I don’t believe in doing things just because IE does it.

The fact is that IE currently has far better support for editable content than Mozilla. I’d really like to see Mozilla have similar capabilities. In cases such as this where Mozilla is playing catch-up to IE and implementing similar, identical, or better capabilities, it often makes sense to use the same syntax as IE. Mozilla has done this in the past (see innerHTML, offsetHeight, offsetWidth). InnerHTML is a particularly interesting example. You could get the same information through the DOM, but it was convoluted, poorly understood, and developers were already familiar with the convenience of innerHTML.

The argument is often made that Mozilla should only implement the “magic” standards defined by outside standards organizations. I see little difference between a standard that is defined by the W3C and one defined by a company, such as Netscape or Microsoft. Implementing a Microsoft-defined standard could be more beneficial than a W3 standard because more sites would be impacted. In the end, I don’t care too much how the standard became a standard as long as we can agree on it and our browsers support it.

As a historical note, the early versions of HTML suffered from a problem typical of standards organizations: they were slow to be defined. This led to innovation and browser-specific extensions and the browser war. The initial versions of IE implemented the Netscape extensions as part of standard behavior. If I’m remembering correctly, HTML 3 was a mishmash where the W3 agreed to simply release a “standard” that matched the extensions in use at the time. They realized that if they waited too long they’d be irrelevant.

Standards organizations can define standards that look good on paper, but are difficult or impossible to implement. Companies that have implementation experience and take that expertise to the standards groups are quite valuable. This means that the companies need to be experimenting and implementing before the standard is defined. The -moz CSS extensions provide some of this and reasonably protect against attributes that are expected to be standardized but which are not fully defined (zoom is an example here).

In the case of editable content, which has been available since IE5.5, Mozilla has some options:

  • Wait for the standard (and I fully expect there will be one—see the first comment of the bug) but be penalized by waiting.
  • Implement a Mozilla-specific format and place additional burdens on web developers to convert their pages.
  • Implement the IE-defined contentEditable attribute and be immediately able to use a number of existing web pages (For a preview see Xopus or Bitflux or other TTW WYSIWYG editors).

Rereading the bug’s comments, I see less flame war, and many people being pragmatic about this. Note that a Netscape developer logged the bug and agreed with the suggestion to use the IE syntax way back in comment 10, long before my comment 150. I like that. The more similar the browsers are, the better for everyone. Isn’t that the point of standards?

Update: Scott Andrew LePera makes similar comments about the Microsoft-defined contentEditable standard. He says “Kudos to the Mozilla engineers for making the right choice: mirror the IE implementation and prevent further fragmentation of the technologies. If and when the W3 catches up, the decision will already have been made. Them’s the breaks.”

Thunderbird mail client

According to the updated Phoenix FAQ, Blake Ross will soon be working on a standalone mail client called Thunderbird. Mozillazine says Thunderbird is simply Minotaur renamed. They are targetting a Thunderbird 0.1 release around the same time as Phoenix 0.5. There’s currently no scheduled release date for Phoenix 0.5, but based on comments that 0.4 will leverage the Mozilla trunk freeze for 1.2 scheduled for a release November 8, we can guess that we’ll see something in November. Blake posted more details about his plans.

I notice that the Phoenix 0.3 release is going to slip a week to around October 14 due to the 1.2beta.

View Source

Since Netscape 1 and probably before that you’ve been able to get the source of a page from the View menu. This has been true in IE for its many versions as well. For whatever reason, in the latest nightly (I expect it will be the 0.3 release) the Phoenix developers moved it to the Tools menu. In the same version, they moved Preferences from the Edit menu to the Tools menu, which is an obvious imitation of IE’s placement of Internet Options. It’s odd that they ignore user expectations for one item and pay attention to it for the other.

They also brought back the Go menu.