Some time in 2006 a friend who was spending time in Cork Ireland sent me a partial copy of an album called “In the Moon” by a band called “Elephant.” I fell in love and ordered 3 original copies which had to be shipped to the U.S. from Cork. At the time it felt a little rash, but the album is really something and I knew the band had broken up, the album was already scarce.

Fast forward a few years. Stuart Murdoch of Belle and Sebastian released “God Help the Girl” a couple of days ago. I excitedly picked up the album on vinyl during lunch today and this evening I settled in to listen all the way through. Within seconds I recognized the new female singer’s voice – Catherine Ireton from Elephants! I always wanted to hear her do more but I didn’t think it’d ever happen. Her rendition of the classic Belle and Sebastian song “Act of the Apostle” is amazing and she’s stunning on the new title track, “God Help the Girl.” Figures that Stuart would have such excellent taste!

About a year ago I was looking at our Mac OS X XPCOM local file implementation in Gecko and I noticed that it is pretty inefficient in terms of the number of system calls it makes for some common operations. I put optimizing that on my to-do list and I’ve now committed most of the big optimizations. Here are the results.

I tested a Firefox 3.6 nightly build (6/24/2009) against Firefox 3.5rc2 by recording all of the filesystem-related system calls each build made during the course of a full standalone talos Ts run. This talos test essentially launches and quits the browser over and over again (about 23 times). I recorded the filesystem-related system calls using the following command:

sudo fs_usage -e -f filesys | grep firefox-bin > ~/Desktop/call_log.txt

The high-level result is that there were 13% fewer filesystem-related system calls made by the Firefox 3.6 nightly build (184,609 vs. 212,253). Most of my optimizations involved moving to a single “stat” system call to get information instead of using Carbon and Cocoa APIs, which often make multiple system calls, particularly if they involve using Carbon FSRefs. Given my intent, it was unsurprising that the Firefox 3.6 nightly build made 32,344 calls to “stat” vs. 15,134 calls for Firefox 3.5rc2. That is a price worth paying for having the Firefox 3.6 nightly build make only 38,250 calls to “getattrlist” vs. 98,965 calls for Firefox 3.5rc2. In case you’re unfamiliar with “getattrlist,” its man page says “you can think of getattrlist() as a seriously enhanced version of stat(2).”

Here are some other results which are interesting because they give you a good idea of how often Firefox makes certain calls. I omitted some less interesting system calls that were made fewer than 3,000 times apiece.

15,134 stat, Firefox 3.5rc2
32,344 stat, Firefox 3.6 nightly

98,965 getattrlist, Firefox 3.5rc2
38,250 getattrlist, Firefox 3.6 nightly

14,290 open, Firefox 3.5rc2
14,196 open, Firefox 3.6 nightly

9,027 write, Firefox 3.5rc2
8,649 write, Firefox 3.6 nightly

20,643 read, Firefox 3.5rc2
20,245 read, Firefox 3.6 nightly

1,325 pread, Firefox 3.5rc2
1,052 pread, Firefox 3.6 nightly

12,230 lseek, Firefox 3.5rc2
11,787 lseek, Firefox 3.6 nightly

7,692 fcntl, Firefox 3.5rc2
7,214 fcntl, Firefox 3.6 nightly

2,096 mmap, Firefox 3.5rc2
1,950 mmap, Firefox 3.6 nightly

I was recently in Arcata, CA, and I met some really awesome rabbits named Gilley and Chumley. Gilley, the girl, is 13lbs and Chumley, the boy, is 10lbs. They stay in the house and even use a litter-box. They’re super happy, especially when they get bananas for a snack in the morning. They like to play in the kitchen because the floor is slippery and they slide around. So awesome – I had no idea that people had rabbits like that for house pets! These pictures are of me feeding them bananas. Gilley licks the plate clean.

Check it out! Created by Mozilla developers Scott MacGregor and Seth Spitzer, among others.

http://www.postbox-inc.com/

Yesterday I became the owner of Gecko’s NPAPI plugin module. Johnny Stenback, the previous owner, remains on as a peer. Given that change, now seems like a good time for an update on plugin module priorities. My current priorities are related to testing, accessibility, and code cleanup.

Automated testing for NPAPI plugin functionality has been highly requested for a while. In bug 386676 I posted a patch that allows for plugin mochitests. The first test gives us coverage for a basic plugin load plus basic npruntime calls into and out of a plugin. As soon as that lands I hope we’ll be adding many more plugin tests and expanding our testing capabilities.

I am working on solutions to two major accessibility bugs, as discussed in this post. We need to allow plugins to reject keyboard events so keyboard commands for things like close-window can work while a plugin has focus, and we need to allow for changing focus from a plugin to other content via the keyboard. Work is slow but steady, things should speed up as other things like testing fall into place.

Gecko’s plugin module is in need of some general TLC. This includes code formatting, dead code removal, renaming/re-factoring for readability, general ugly/outdated code auditing, and sample modernization. I landed some of that already and I’m hoping to land a bunch more over the coming months.

I’m not ready to write about longer-term priorities yet, things like out-of-process plugins. We are thinking about them though, I’ll have more information in January or February. In the mean time I’m looking forward to making a lot of progress on things that will make the bigger changes easier to digest.

New York is a fantastic city. I spend a fair amount of time there and today was just such a nice day I feel like writing about it.

I woke up this morning at a friend’s place in Spanish Harlem, the sun shining brightly through the windows – it was a beautiful day. We walked to a bakery and got coffee and croissants, then we walked to a nearby park and watched a largely Puerto Rican baseball game for an hour while we drank our coffee. The players were probably 14 years old and having a lot of fun. A guy rode by on a bicycle flying about ten Puerto Rican flags, honking a little horn constantly and smiling at everybody.

After the game I walked South, from E 112th & 2nd to around E 78th & Madison. It is a nice walk, interesting because you get to see the transition from Spanish Harlem to the wealthy Upper East Side. My friend is a teacher and she was recently talking to her kids about health. She suggested focusing on what food is readily available on each block of the walk. Nutrient value, pricing, cuisine diversity… speaks volumes.

Madison Avenue on the Upper East Side has a lot of fashionable clothing stores and some great people-watching. I ended up having lunch with Hal Hackady at a diner near there, where he introduced me to rice pudding with whipped cream and chocolate sauce and gave me some good advice about new strolls through Central Park. Hal also drew a picture of me on a napkin while I was staring off at something:

I like that he didn’t use a clean napkin.

After Hal and I parted ways I headed into Central Park and watched people sail little boats in the pool near 75th on the East side of the park. It is a busy part of the park on weekends, but sitting there on weekdays can be really peaceful.

I’ve added two new peers to the “Widget – Mac” module (Cocoa widgets), Steven Michaud and Markus Stange. They have both done great things for the module and working with them is a pleasure. Steven has contributed a huge number of fixes for tough bugs over the past two years, focusing on event handling, plugin interaction, and crash debugging. Markus joined us earlier this year and has gotten up to speed very quickly. He has contributed many fixes focusing on theme and OS integration issues.

Thanks Steven and Markus!

Recently I have been doing some work to make life easier for NPAPI plugin developers. As part of that effort I started to revive our NPAPI SDK and rewrite some of our sample code. Today I’m going to explain how to write an NPAPI plugin for Mac OS X, based on the basic sample plugin in our SDK. It is actually pretty easy now. You can have one built and running in the browser in minutes.

The sample code I’m going to be referencing today can be found here:

http://mxr.mozilla.org/mozilla-central/source/modules/plugin/sdk/samples/basic/mac/

We decided to commit that sample under a BSD-style license which means you can use it for anything, even if you don’t plan to release source code. This is unfortunately common for NPAPI plugins.

If you check out the Mozilla source code in Mac OS X, you can simply open “BasicPlugin.xcodeproj” and hit build and you’re done. A “build” directory will be created next to “BasicPlugin.xcodeproj”, and if you built in release mode that will contain a “Release” directory with the plugin inside it. Copy that plugin into one of the following two locations and it’ll work:

/Library/Internet\ Plugins/
~/Library/Internet\ Plugins/

Just modify the basic sample plugin to do whatever you want.

Now I’ll explain some things that might not be obvious if you were trying to get such a plugin building on your own.

The plugin communicates its MIME and extension information using the “Info.plist” file which is packaged in the plugin bundle. Just read the file to see how that is done. The plugin also communicates its bundle type in that file, under the key “CFBundlePackageType” – the type is “BRPL”. If the type is not an NPAPI plugin type, the bundle won’t load as an NPAPI plugin. You can just always use “BRPL”.

I made a GCC preprocessor definition in the project file, “XP_MACOSX=1″. This is used by the NPAPI headers, if you don’t define it they won’t be interpreted correctly on Mac OS X. This is easy to miss in the sample project file build settings.

Symbol visibility is a common problem area for people trying to get NPAPI plugins working. Some symbols must be visible as standard C symbols so the browser can find them, which (always?) means simply prefixed with an underscore (Foo() = _Foo). There are three symbols that need to be visible as standard C symbols on Mac OS X – “NP_Initialize”, “NP_GetEntryPoints”, and “NP_Shutdown”. Our sample plugin is written entirely in standard C and uses a standard Xcode build configuration so by default all of its symbols are C-style and visible. If you wanted to implement your plugin in C++ (.cpp) or Obj-C++ (.mm), you would have to do this:

#pragma GCC visibility push(default)
extern "C"
{
NPError NP_Initialize(NPNetscapeFuncs *browserFuncs);
NPError NP_GetEntryPoints(NPPluginFuncs *pluginFuncs);
void NP_Shutdown(void);
}
#pragma GCC visibility pop

You can check to see if your symbols are visible and in standard C naming format using the “nm” utility on Mac OS X, targeted at the plugin binary. The results should look like this:

[josh@denmark MacOS] nm BasicPlugin
...
00000810 T _NP_GetEntryPoints
000007fa T _NP_Initialize
000008a0 T _NP_Shutdown
...

This basic knowledge should get new NPAPI plugin developers pretty far on Mac OS X. Soon I’ll write up the same thing for getting an NPAPI plugin working on Linux/UNIX systems.

I’ll be giving a talk about the Mozilla project at Independents Hall in Philadelphia on Wednesday, September 17th, at 6:30 PM. The talk will include an overview of Mozilla’s software development process and our organization.

Independents Hall is located at 32 Strawberry Street in Old City Philadelphia.

I want to talk a little bit about Mozilla NPAPI plugin bugs 78414 and 93149. I’m surprised by the fact that more people don’t complain about them given how irritating they are, particularly on Linux and Windows. We have an ugly hack on Mac OS X that mitigates the problem so it isn’t as much of an issue there, but the hack violates NPAPI and it’d be nice to not have to use it.

Here’s how annoying these bugs are, you have to use Windows or Linux for this example to work:

1. Open a new window in Firefox.
2. Go to a YouTube video, I suggest this one (I wouldn’t rickroll you, pinky swear!).
3. Click in the plugin, either on the video or the pause button or wherever.
4. Hit ctrl-w in an attempt to close the window.

Surprise! The plugin ate the keyboard command and the window is still open. It’ll eat tab key presses too, so you can’t tab focus away from the plugin. I don’t know how Windows and Linux users can stand this. At least on Mac OS X we let any keyboard commands in the native menu bar have first crack, and if they don’t do anything then we let the plugin have the event. This is a problematic and incomplete solution though, I won’t get into it here except to say that doing the same thing on Windows and Linux would be nasty. We need to fix the problem the right way, which will probably be a bit of a slog because it’ll most likely require changes to NPAPI and a fair amount of discussion between browser and plugin vendors.

In addition to being irritating, these bugs are problematic in terms of Section 508 compliance, which “requires that Federal agencies’ electronic and information technology is accessible to people with disabilities.” They can go on any list of reasons for federal agencies not to use Mozilla products.

We’re going to be looking into fixing these bugs soon, stay tuned…