Last week I was in California. It was my first time in the Mozilla SF office --- lovely view of the Bay from the roof. I always enjoy the free snacks and I'm always glad we don't have them in Auckland. I spent quality time with some of the people I know and love at Mozilla, and that's always exciting.

On Wednesday and Thursday I was at Half Moon Bay doing LEAD training. It was fun, but thinking about "soft skills" for two days straight is quite draining for me; my social skills are learned, not innate.

This cohort is different from previous cohorts --- most members are relatively new to Mozilla; of our cohort, Vlad and I have been at Mozilla the longest, by far. This gives me the honor and duty of representing the Mozilla old guard. I feel the power of the narrative that has me in the "crusty old engineer, harping about the old days and resisting change" role ... and I do my best to reject it :-).

One of the results of LEAD so far is that I perceive my relationships with other Mozilla staff to be warmer and stronger than they perceive them, on average. I suspect this may be related to the difficulty of maintaining deep relationships with remote employees I see a few times a year at best. I'm still trying to figure that out.

Plane movies:

• Gangster Squad: Genre flick. OK.
• Zero Dark Thirty: Pretty good. Not exactly entertaining, but interesting.
• Live And Let Die: Some kind of cross between a Bond movie, a blaxploitation flick, and the Dukes Of Hazzard. Odd.
• The Town: Genre flick. Slightly better than average.
• I, Anna: Sort of noir-ish psychological thriller. OK.
• Les Miserable: The movie of the musical. Pretty good. I need to read the book sometime.

Interestingly, Air New Zealand lets you see what movies they're showing on their routes. This Web interface is a pretty faithful mockup of the actual in-seat interface (which is pretty bad ... it would be great to be able to see more than one movie title at a time).

On Friday I leave for Taiwan for a week at the Mozilla office, a "Web rendering" work week. This should be even more fun than last week.

Over time I've become increasingly impressed with the broad applicability of Matthew 18:15-17:

If your brother or sister sins, go and point out their fault, just between the two of you. If they listen to you, you have won them over. But if they will not listen, take one or two others along, so that ‘every matter may be established by the testimony of two or three witnesses.’ If they still refuse to listen, tell it to the church; and if they refuse to listen even to the church, treat them as you would a pagan or a tax collector.

The first step is often difficult but crucial. The path of least resistance can be to go behind your antagonist's back --- to your friends, or their friends, or their manager. I've seen all kinds of negative consequences from following that path --- hurt, distrust, unnecessary escalation, confusion and fear. I feel my integrity depends on people knowing that whatever I say about them to others, they will not be surprised by because they've already heard it from me.

This applies in the other direction too, when people complain about third parties to me. If the third party is unaware of the issue, I don't want to know --- go away and talk to them first.

There are rare exceptions, usually involving time-critical emergencies or complex secrecy requirements.

Our Web Audio implementation is making great progress. This is mainly due to the efforts of Ehsan Akhgari, who is, astoundingly, cranking out one or two features per day. Paul Adenot and I are spending hours every day just reviewing his code. I think this is partly due to Ehsan and I laying down some pretty good infrastructure at the outset.

Our current goal is to have a basically complete implementation for Firefox 24, which branches from trunk in about eight weeks. There are a few things we need to do to get there:

• Complete the feature set. At this point that mainly means adding all the node types that aren't implemented yet: MediaStreamAudioDestinationNode, MediaStreamAudioSourceNode, MediaElementAudioSourceNode, ConvolverNode, OscillatorNode, and WaveShaperNode. The first three are all related and shouldn't be too hard since we designed Web Audio from the start to share infrastructure with MediaStreams (which are already integrated into media elements) --- internally, a Web Audio node is just a special kind of MediaStream. We still need to implement HRTF and soundfield panning modes for PannerNode. We need to implement OfflineAudioContext. For some of the audio algorithms that aren't very well specified, we're borrowing code from Blink. This is suboptimal but there's ongoing discussion about what level of detail we should specify the audio algorithms at.
• Work on latency. Right now audio output has pretty bad latency, especially on Android, FirefoxOS and Windows; the biggest problems are intrinsic issues with the platform APIs we're using. On older versions of Android and Windows XP it may be a lost cause, because good APIs simply aren't available. For Windows Vista and up we're writing a new audio output backend using WASAPI. On FirefoxOS we may rip out the Android code we're using and replace it with PulseAudio. There is additional work to do to better integrate the MediaStreamGraph (that drives MediaStream and AudioNode processing) with our libcubeb audio backends for lower latency and better tracking of the audio clock. This latency work is desperately needed for WebRTC as well as Web Audio.
• Work on throughput. Right now we're focusing on having a good clean design and functional correctness. For example, all communication and synchronization with the MediaStreamGraph real-time processing thread is asynchronous, using message passing. Updates to Web Audio and MediaStream graphs are batched so all changes performed by a script happen atomically on the real-time thread. But we haven't done any profiling, tuning, or optimization of the actual processing code. In particular we'll clearly need SIMD implementations of basic audio primitives such as mixing to get near-maximum performance, especially on mobile.
• Test and fix bugs, needless to say.

Contributors welcome! The Web Audio bug (779297) has a lot of dependencies to choose from :-).

One interesting issue that Jean-Marc Valin brought up recently is the prospect of a loudness war on the Web. Some areas, such as Sony's Playstation products and some broadcast TV regions, are trying to mitigate the loudness war by standardizing acceptable dB levels for all content. It might be a good idea to do this on the Web too, and have browsers automatically limit the volume of content that exceeds those levels. We're still thinking about whether and how this should be done, and talking about it on public-audio.

We had a lovely few days away. On the drive to Rotorua we stopped at Waihi and rode the old railway up to Waikino in an open carriage. Later we stopped at Mount Manganui and walked to the top --- always a great view.

We stayed by the lake at Waiteti, just out of town, at Waiteti Lakefront Motel. I think that was a pretty good decision; very peaceful, great view, relatively cheap, and free use of kayaks which we took advantage of on Saturday morning, paddling up the Waiteti Stream a bit.

On Friday morning we did the gondola and luge ... especially the luge, which everyone enjoyed. After that we visited Kuirau Park, which I always enjoy a lot --- it's so great to have a geothermal park right in the city. Then we went to Waimangu Valley, which I still think is the best geothermal attraction in the area because of its unique size and features, and its brilliant bush and lake setting. It's changed noticeably since I was last there; Warbrick Terrace is growing quite rapidly.

After kayaking on Saturday we went to the Redwoods for a short walk. I hadn't been there before and it's really great --- not as picturesque as some other places near Rotorua, but large and lovely, especially I imagine for running and biking. Then we went to Lake Okareka and did the new walkway there. Brilliant.

On the way back to Auckland yesterday we stopped near Putaruru and did the Te Waihou walkway. The Waihou river is stunningly clear and beautiful due to having flowed underground through filtering rock in the Kaimai Ranges (for fifty years, supposedly). We saw a lot of trout, but a couple of guys fishing complained they hadn't caught any because the clarity of the water made it too hard to estimate depth!

All in all, another wonderful central North Island getaway. I love this place.

Postbox 3.0.8 is now available. Here’s what’s new in this release:

To update, select About Postbox from the Postbox menu on Mac OS X, or select About Postbox from the Help menu on Windows, then click the Apply Update button once the update has finished downloading.

We drove out to the Upper Mangatawhiri Dam on Sunday afternoon and took a couple of hours to get to Piggotts campsite. It's a pretty small patch of flat grass, so I don't know how you'd get 20 people camping there, but whatever. There's also a small hut which I haven't seen mentioned anywhere. In fact we passed by it, thinking that couldn't be the place, but quickly turned back when it became clear that it was, in fact, the place.

A thunderstorm passed over during the night. It was the first time any of us have been in a tent during a thunderstorm, so that was exciting for everyone.

The next day we got up early and hit the trail about 8:15am. Based on the warnings about central Hunua tracks being "for experienced trampers only", and that we hadn't ever hiked a long distance carrying all our gear, I wanted to give us the maximum possible time to get to Adams campsite. As it turned out even the warning-est track (Upper Mangatawhiri) was just fine. Less fine was that the Adams campsite was a lot further along the track than where my map shows it, and when we finally found it at about 3pm, it looked pretty awful. The ground was waterlogged and, while there was a sign saying "toilet", there wasn't one to be seen. We decided to skip it and push on to our final destination --- Waharau Regional Park. (Now that I've looked a bit closer online, it seems Thousand Acres campsite is a better bet ... but it's not even on my map. Lesson: use up-to-date maps and do more research!)

So our three-day tramp turned into a two-day tramp and we arrived at Waharau about 5:15pm after nine hours of tramping, covering about 18km of reasonably rugged terrain with all our gear. Everyone was tired but I'm proud of my kids for handling it very well.

If the weather forecast isn't too horrible I'll be away the coming Sunday afternoon to Tuesday morning tramping in the Hunua hills southeast of Auckland.

Thursday is Anzac Day, a public holiday, and I'll be taking Friday off to go on a holiday with my family. So I'll probably be in the office/online only on Wednesday next week (that's Tuesday for those of you on the wrong side of the date line).

About a week later, Sunday May 5, I have a flight to San Francisco. I'll be in the Bay Area on Monday and Tuesday, and at LEAD training on Wednesday and Thursday.

About week after that, Friday May 17, I'm flying to Taiwan for a Mozilla layout/graphics/media work week.

Fun times!

The head of "Google NZ", Tony Keusgen, has been talking about New Zealand's shortage of "IT experts". And apparently, unlike most people who complain about it, he's actually tried to do something to help. That's great.

However, what's not so great, and of course not mentioned at all in the article, is that Google itself is contributing to the problem in a significant way by aggressively recruiting for NZ developers to move to their Sydney engineering office --- since they don't have an engineering office in New Zealand. That works for Google, for their recruits, and even for me and Mozilla, since there's basically no competition to Mozilla for NZ developers who want to do the sort of platform engineering work we do. It sucks for New Zealand though.

It's too bad the writer, Ben Chapman-Smith, didn't know about or declined to mention this. And if no-one called Tony Keusgen on it, that's bad too.

I would love to see a real Google office here. Some pretty high-profile Googlers are NZers. Make it happen!

I just sent a message to public-audio replying to Chris Rogers, Chris Pike and Chris Lowis. Fortunately Chris Wilson wasn't involved in the thread, although he could join at any moment.

It reminded me of a Mozilla meeting discussing multi-process video playback, which I attended with Chris Double, Chris Pearce, Chris Jones and Chris Blizzard.

Something is deeply wrong here.

I went to an orienteering event on Saturday. Orienteering is a race through a set of waypoints on a map; what sets it apart from a regular running race is the need to navigate via the map. Obviously it would be easy to cheat with a smartphone. Currently it's not hard to ensure people don't carry or use smartphones during the race. However, it's going to get increasingly difficult to detect cheating as technology progresses into smartphone watches, Google Glasses, and ultimately body implants. It doesn't seem practical to use X-rays or MRI scans on every participant, even if that would work.

Similar cheating problems are already happening in chess, and in written exams. Casinos grapple with these issues too.

It seems likely that any competitive event where real-time computer assistance (including communication with other humans) would be useful will sooner or later become practically impossible to secure against cheating. This will have profound effects. Even when people choose not to cheat, not knowing whether the game is fair is corrosive. Enjoy competitive games while you can.

This is going to be a problem for job interviews too.

I blogged last time the browser engine count changed, so I think to be fair I should blog about this one too.

I think this is good news for the Web. When we lost an engine, that was bad for engine diversity and the open Web. Now we're gaining one, and that's good for engine diversity and the open Web. It's not a direct reverse of the Opera situation though. Compared to Presto, Blink will have much more market share, and therefore a bigger impact. On the other hand, Blink is a promise to deliver a different engine over time, not a new engine right now, and even in the long term one presumes it will share a lot of code with Webkit --- especially if people port code between the two projects. So it contributes less diversity than Presto did.

One immediate benefit for the open Web is that today it's difficult for mobile Web developers to advocate "just coding to Webkit" as the way forward.

One issue we'll need to figure out in standards groups is when a Webkit implementation and a Blink implementation of a feature count as two independent implementations to allow a spec to proceed to REC. It's tough; even if the implementations are developed independently, the shared context (both code and architecture) will make the implementations less independent than they should be. We may need to address this on a case-by-case basis.

I am a bit worried about how this will impact Apple's support for the open Web. Safari has lagged behind other browsers in various ways, but they were also dragged along by Google to some extent in supporting new features whether they cared or not. Now they're falling completely off that train and we'll see a true test of whether Apple is willing to step up their investment to keep up with the progress of the open Web. Apple has obvious incentives to hobble Web apps on iOS, so I worry.

Of lesser importance, this is probably good for Mozilla. Even if it means Chrome moves faster, the fracturing of the Webkit community benefits us. It's not something to gloat over though.

Back to work!

Update One other thought occurred to me: now, a company adopting Webkit has to choose between a fork dominated by Apple and a fork dominated by Google. That's going to be less appealing than when Apple and Google were providing some counterweight to each other.

The latest browser usage stats are out at Net Applications:

Firefox has been mostly stable over the last year with Chrome down about 15% from its high. The increasingly solid IE 9 and 10 browsers have helped reverse Microsoft's slide, putting them solidly in positive growth over the last year.

A lot of exploit styles (e.g. "return-oriented programming") rely on jumping or calling into code that was never meant to be executed "stand-alone" --- i.e., jumping to an instruction that was only ever supposed to be executed by falling through from the previous instruction or via a branch within its function. On x86 this includes destination "instructions" that are actually part of another multi-byte instruction. It seems to me these exploits could be made much harder by somehow marking the start of "valid" branch/call/return targets and faulting when control is transferred to other instructions inappropriately.

Here's a more specific proposal for x86:

• Add a new flag bit for code pages to enable "destination checking" on a per-page basis.
• An indirect control transfer is any return instruction that pops EIP off the stack, or any jump or call instruction whose operand is not a constant. When an indirect control transfer jumps to a page marked for destination checking, and the instruction at EIP is not 0x90 (NOP), fault.
• A toolchain would take advantage of this feature by marking code pages for destination checking, avoiding use of 0x90 for regular NOPs, and placing a 0x90 at every function entry point and after every call instruction. For bonus points, avoid generating 0x90 bytes inside other instructions.

Obviously there are a lot of ways to tweak this. For example "PUSH EBP" is very often the first instruction of a function, so you could whitelist that instruction as a valid function entry point. You could avoid having to place a NOP after a direct CALL instruction by checking if the instruction at EIP-5 is 0x9A (direct CALL). You could make false returns even harder by extending that special case to require the address we're returning from to be "close to" the destination of the direct CALL instruction.

This is obvious enough that I presume someone's worked on it already.

For several years Crazy Noodle Bar was one of our favourite restaurants in Newmarket. It served cheap tasty Hong Kong cafe food --- a mix of Chinese dishes and Chinese-style Western dishes. Last year it went on hiatus for six months and moved to another building a few blocks away. When it reopened, the menu quickly evolved away from its previous incarnation although there was still a resemblance and it was still pretty good.

A more disturbing change was the new decor, whose distinguishing feature was retro posters of Chairman Mao. He's an iconic figure in China, but he's also one of the top three most murderous dictators of the 20th century, so not someone I want to see celebrated. I put up with it.

It got worse. The staff showed up with Chinese military-ish uniforms, green with red epaulettes. Then last week, the name changed to Red Guard Noodle Bar. This is really the last straw. The Red Guards were Mao's vanguard of the Cultural Revolution, which was an awful and disastrous episode of Chinese history. I don't know what the proprietor of the cafe is thinking, but I'm not going back.

As an aside, I don't know why this isn't a scandal. Imagine the outcry if someone opened a "Stormtrooper Cafe" decorated with swastikas and pictures of Hitler and Röhm. I suppose it's because Mao mostly restricted his brutality to his own citizens.

I'd feel worse about the decline of traditional media if it wasn't so disappointing when they write about issues I have first-hand knowledge of.

Today's example is a story about the lack of pedestrian access from Gilles Ave to Broadway under the new Newmarket Viaduct. The article records complaints from Cameron Brewer and Andy Smith about how the project has neglected pedestrians. Reading it, you'd think a walkway would be a real boon for pedestrians accessing Newmarket. But a glance at a map shows the truth: every route along Gilles Ave to the under-Viaduct area must pass Alpers Ave or Mortimer Pass, both of which also provide direct access to Broadway. Therefore a walkway under the Viaduct would shorten the journey to and from Newmarket for approximately zero pedestrians. (I say this as someone who walks to work in Newmarket every day, often along Gilles Ave, and could actually use this walkway regularly.)

I'm ambivalent about whether this walkway should be built. On one hand it would be nice to have and I've been looking forward to it. On the other hand perhaps our money could build a new pedestrian route that's actually useful. But the quotes from Brewer and Smith, and the tone of the article, are overblown and misleading, and the introduction of a few geographic facts would have cleared things up. I won't mourn the loss of journalists who can't or won't do this.

Recently Pascal Finette quoted Tom Chi as saying:

When you come home from your job in the evening and pretty much all you want to do is slouch on the sofa, watch a movie and have a beer: Quit your job.

There have been many times when that's all I've wanted to do. Does that mean I should quit my job? No.

Before I worked full-time on Mozilla code, my job was computer science research. I'd have to say that was more fun and intellectually stimulating than my job at Mozilla. Does that mean I should quit my job? No.

I work at Mozilla because I think God gave me talent to use for the maximum good of all, not for self-gratification. I work at Mozilla because it's the most important work I can imagine doing. And it's not just me; one of the great things about Mozilla is that many, if not most, of its people have a similar kind of motivation. Mozilla is full of very smart people who have spent years dealing with difficult and frustrating problems, often turning down lucrative offers to do other things, because they believe in what we do. I love them for it.

It would be nice if important tasks were always exciting, energizing and exhilarating. But real life just isn't always like that. Making Flash less painful for our users, or tracking down bizarre graphics driver bugs, or struggling to convince megacorporations to do the right thing, is just draining.

However, it's important to keep a sense of perspective. Most of us are paid ridiculously well to do a job which is generally less stressful or challenging than many other kinds of work. If we make a few small sacrifices, no-one should be overimpressed.

In the media scrum around the papal election, a lot of commentators called for the Catholic church to "modernize" to "stay relevant". As a Protestant I agree my Catholic brothers and sisters could make changes for the better, but "modernizing to stay relevant" has often been a siren song that has, and still does, lead many Christian groups to heresy, torpor, and --- ironically --- irrelevance.

The problem is that calls for "relevance" tend to promote the erosion or rejection of tenets of the historic Christian faith --- such as belief in miracles, divine judgement, the authority of scripture, or even the existence of God himself --- in an effort to make Christianity more palatable to modern people. Many Protestant denominations have wholly or partly gone down this path, including New Zealand Presbyterianism of which I am a member. The effects have been disastrous along many axes. Many congregations have ceased to be Christian in all but name, and are incapable of carrying out God's work in the world. By refusing to officially apostasize, they create vast confusion over what Christianity means and (further) undermine the unity that Jesus' followers should have. And instead of making Christianity more appealing, this drive for "relevance" ultimately kills the congregations that follow it. It's easy to see empirically: unbelieving congregations tend to age and dwindle, and healthy and growing congregations tend to be more orthodox. These trends make perfect sense: if a congregation loses its "saltiness" and becomes a secular club with Christian trappings, why would the average person prefer it over another secular club without the tomfoolery? Not to mention that there can be no evangelism, no spiritual regeneration, and no working of God beyond common grace.

The institutional hegemony of the Roman Catholic church has a lot of downsides, but it has enabled them to mostly avoid going down this path --- for which I am grateful. I pray that they'll continue to ignore misguided calls to change course.

For the church to stay relevant, we must keep teaching the classic gospel of Jesus and keep making disciples in his name. To increase our relevance we need do nothing new, but do the old things better: more Christian unity, more evangelism, more faithful living, more prayer, more love. This won't happen with sweeping pronouncements, election of Popes, or even writing of blogs, but as individual Christians quietly choose to put Jesus ahead of themselves every hour of every day.

Attention Boeing, US Department of Defense, and everyone else: Please stop automating your planes, armies, etc and connecting them to computer networks. Their security will fail and you will lose control of those assets, with dire consequences.

Seriously, why can't everyone see this? Was Lockheed being hacked via RSA not a clear enough sign?

It's US military's conversion to drones that worries me the most in this vein. There's some seriously asymmetric warfare coming.

Canonical's new Mir display server, and the discussion/controversy around it, illustrate some of the technical advantages of FirefoxOS.

By supporting nothing but Web applications, we've raised the level of abstraction for our platform APIs so applications are completely oblivious to how cross-process rendering and event delivery are implemented. We can evolve our implementation and our IPC protocols at will without breaking applications. (In fact we're in the middle of doing just that.)

Because Web applications expose a scene graph, we are able to gather scene graphs across processes, and combine and composite them together in the compositor process. Exchanging scene graphs instead of just surfaces lets us do sophisticated effects such as animation and scrolling of application content directly in the compositor. That has some complexity, but it's less complex and more efficient than having apps independently do their own compositing and coordinate with the system compositor.

Then it's interesting to consider what happens when you run Web apps on a non-Web mobile platform. You have to load up a browser stack that's going to look quite similar to FirefoxOS, and run it on top of the native stack and system compositor, much of whose functionality it duplicates. There's significant overhead there compared to FirefoxOS.

Avoiding that duplication also means there's less work to do for us developers. Most of the cross-process compositing work we've done for FirefoxOS is generic work that pays off for Firefox all platforms. In fact, that's true for most of the Gecko work we've done (and will do) for FFOS. For a small organization like Mozilla that needs to punch above its weight, that's critical.

Having said that, in the rush to get FFOS ready for market we've gone out on a limb a bit and created a number of features that only work in FFOS currently. A big theme for our development in 2013 is to get those features working on all the other platforms. This will benefit the Firefox product on those platforms and also make our developers' lives easier.

Today there's an email to the www-svg list which illustrates perfectly the value of browser engine diversity. This kind of thing happens all the time.

To be clear, browser engine independence pays off here because it tells the Web developer that there is a real choice of behaviors. The developer can say "oh, that behavior is definitely better" instead of just "oh, how strange". It also gives us implementors confidence we can change the behavior since Web content (if it's been tested in multiple browsers) can't be depending on one particular behavior. It also tells us that the Web developer's preferred behavior is actually implementable.

The news about Opera switching to Webkit is disappointing. It's a sad day for the Web, since I thought highly of their Presto engine and their Web standards work. Their impact on Web standards will be dramatically reduced, especially where they want to do something differently to Apple and Google. The big loss for the Web is a further decrease in the diversity of browser engines, especially on mobile devices. This means that our work at Mozilla simultaneously becomes more important --- we now have one of the three viable browser engines, instead of one of the four, and engine diversity is already critically endangered --- and more difficult, because this will strengthen the Webkit mobile monoculture and make it even harder for us to promote Web standards over "coding to Webkit".

Some people are wondering whether engine diversity really matters. "Webkit is open source so if everyone worked together on it and shipped it, would that be so bad?" Yes. Web standards would lose all significance and standards processes would be superceded by Webkit project decisions and politics. Webkit bugs would become the standard: there would be no way for developers to test on multiple engines to determine whether an unexpected behavior is a bug or intended. It wouldn't be the worst possible outcome --- victory of a closed-source engine would be worse --- but it would be a far cry from the open Web goals we've been striving for.

So, back to work!

On Tuesday, our preliminary Metro Firefox development work arrived at mozilla-central, the source code repository that feeds the Firefox Nightly channel. This means that if you are on the Firefox Nightly channel and you have a Windows 8 device, your Wednesday Firefox update should deliver a Metro Firefox tile to the far right end of your Windows Start screen.

There's plenty of work still to do, but it's stable enough that we're ready for more and more regular testing. If you're a Firefox or Windows developer and you'd like to get involved, please let me know.

Yesterday was a public holiday and the weather was brilliant so our family went to Waiheke Island for a walk and to check out the sculpture trail that's currently in place there. We discovered that thousands of other people had the same idea --- the ferry terminal was by far the busiest I've ever seen. Three cruise ships being docked downtown probably had something to do with it! We had to wait for about an hour to get on a ferry, which was annoying but it gave us an excuse to talk to the strangers around us, which was great.

Once we finally reached the island about 11:45am we did a long-ish route from the terminal at Matiatia, to Oneroa beach on the north side of the island, across to Blackpool on the south side, past the Piritahi Marae, across the hills to Church Bay on the west side, and then around the coast north back to Matiatia. It was hot and sunny but we were able to walk in the bush or in sea breezes most of the time so it was very pleasant. The sculptures were a lot of fun. We got back to Matiatia around 4:15pm.

The other major walk option at the west end of Waiheke is to walk along the coast from Matiatia north and east to Oneroa. When the sculptures aren't in place I'd say the northern walk is a bit better --- although if you're a gourmand with plenty of spare cash, the southern walk has the option of stopping at Mud Brick restaurant for lunch, which is pretty great. (We didn't do that yesterday, but I went there on Novell's budget once.)

Last week the desktop Firefox team got together in Toronto, Ontario, Canada to do more planning for 2013, hacking on key initiatives, and team building. We had attendance from Engineering, User Experience and User Research, Product, and Innovation/Labs, totaling just under 30 people.

On Monday Johnathan Nightingale and I presented the latest thinking on target markets, industry assumptions, and feature roadmaps for 2013. We were also treated to an amazing trio of presentations from Ed Lee of Innovation/Labs, UX's Madhava Enros, and Bill Selman from UR.

On Tuesday, the whole team participated in an ideation session led by Madhava and Johnath that resulted in an exciting collection of short and long term work items.

The ideation session started with a re-cap of some of the themes from the previous day's planning talks and instructions for everyone to write down as many ideas for Firefox improvements as we could. We posted all of those ideas up on the big wall and then started clustering them -- grouping similar items and labeling those areas.

Here's a picture of the big wall before clustering.

Photo by DoNotLick, and used under a CC license.

And after.

Photo by DoNotLick, available under "she gave me a link to it" terms and conditions.

The ideas clustered into about three dozen areas including Transitions & animations, Kill URLs, Translation, Search, Sharing/emailing/social, Flash, Crash reporting, Platform integration, Tabs, Add-ons and feature integration, Preferences, User created content, User switching, Evergreens, Privacy, Self healing, Help, Humor, jokes & whimsy, Remote control, Add-ons management, Sync & Backup, Profiles & import, Paper cuts, Web Apps, Performance, Personalization, First run, Discovery & suggestions, Passwords, Australis, Network, Save for later, Developer tools, and Download manager.

From there, the team selected about a dozen items to design, prototype, and demo during the remainder of the work week. On Thursday, break-out teams presented the results of that work.

Mike Conley (mconley) and Matthew Noorenberghe (mattn) presented the work they'd done to increase the performance of the upcoming Australis tabs re-design. They worked with the graphics team (several of whom are conveniently located in the Toronto office) on some new approaches and their presentation concluded with a chart showing approximately 30% performance improvement on low-end hardware (a netbook.) Australis is getting closer and closer so this was some really valuable work. Not only will Australis be beautiful, it will be very fast.

After the Australis tabs demonstration, Mike Conley gave a preview of tabs working in the title bar in Mac, a hard-fought victory that will allow the Australis team to implement the planned design properly on OS X.

Next up was Shane Caraveo (mixedpuppy) who showed some of the exciting improvements he's got working for the Social API, including the ability to install new social providers from the Web, enabling and disabling of service providers within the Add-ons manager, and an initial implementation of the Share feature.

Following the Social improvements was Gregory Szorc (gps) with some great work on improving memory usage related to the upcoming Firefox Health Report feature.

Jared Wein (jaws) had three pieces of work to share. First was his work on identifying and warning users about extremely slow start-ups. He followed that up with a nice demo of animating the transition between showing and hiding the Find in page toolbar. And last but not least, jaws showed some nice updates to the style of error pages in Firefox.

Next we heard from and saw demonstrations by Marco Bonardo (mak), Asaf Romano (mano), and Ed Lee (mardak), which included breaking the star bookmarks button out of the address field and combining it with the bookmarks toolbar button, and User Profile integration with Firefox.

Zhenshuo Fang (fang), was up next and shared a bunch of investigation and ideation that UX/UR, Engineering, and Product had done during the week on the Firefox first run experience and the various ways it could be improved. The ideation session here clustered into Celebrating users, Instantly personal, De-cluttered, Australis introduction, Help make Firefox my own, and Firefox boot camp. You can dig in to those ideas here.

Up next was Bill Selman (wselman) who presented some of his work on designs to improve crash reporting and in product help.

Justin Dolske (dolske) shared some of the opportunities that he and a break-out group enumerated for adding more whimsy to Firefox, including an add-on that updates the new tab about:blank placeholder text in the address bar to make it less dry and much more human and inviting.

Christian Sonne (cers), demonstrated the moving of much hated missing plug-in infobar into a simpler and less obtrusive notice in the address bar.

And last but not least, Felipe Gomez (felipe) presented the findings that he and his break-out group developed around captive portals and how Firefox can identify when it's accessing the internet through a captive portal as well as some ideas about handling the restoration of tabs failures that happen when connecting through a captive portal.

There was a lot more than this happening during the week, including some core Firefox hacking and lots of discussion, problem solving, small scale direction setting, etc., etc. There's just nothing quite like getting a geo-distributed team together in one place for a few days of concentrated effort. I can't wait for the next Firefox work week.

update: Jared posted a great write-up also.

OpenType is the industry standard font format. This is good. However, OpenType fonts severely limit what can be drawn in a glyph: basically, you can fill simple paths, and that's it. Some use-cases, e.g. fonts for emoji, require colored and even animated glyphs. SVG is the vector graphics format for the Web platform, so it makes sense to support SVG content in glyphs. The SVG Fonts spec defines a non-Opentype SVG-based font format which in theory lets glyphs contain any SVG content. However, this format has some deficiencies that I believe make it unsuitable for the Web:

• SVG Fonts have very weak shaping support, which makes them unusable with Indic and other languages. A solution which is unusable by a large fraction of the world's population is inadequate for the Web.
• As a side effect, SVG Fonts do not support advanced typographic features that are offered by OpenType and are being exposed to Web authors via the CSS3 Fonts spec (e.g. stylistic alternates).
• SVG Fonts have a somewhat broken model for how style on the text affects rendering of the glyphs: CSS style inherits directly from the text to the glyphs. This is difficult to implement in a performant way, and doesn't do what authors expect.

The Web needs an approach that overcomes these problems.

Introducing SVG Glyphs In OpenType!

We propose to extend OpenType with support for glyphs consisting of SVG content. A new "SVG" OpenType table is defined, containing one or more SVG documents, each of which contains one or more glyphs. It's almost as simple as that! SVG glyph documents are subject to the same restrictions as SVG image documents, i.e. animation is supported but not scripting or external resource loads. CSS style is not inherited from the text to the glyphs; instead, the stroke and fill property values of the text are available in the glyphs document as new CSS values "context-fill", "context-stroke" etc. (These new values would also be useful with other SVG features such as markers.)

This proposal has been implemented in Firefox. It's disabled by default (in order to not pollute the Web with our not-yet-standardized implementation), but can be enabled by toggling gfx.font_rendering.opentype_svg.enabled in about:config (test page here). The only significant missing feature in our implementation is that animation is not yet supported. There are some bugs :-). Currently "context-fill" etc are named "-moz-objectFill" etc.

This approach has some nice advantages:

• Very simple spec and implementation. This proposal only affects glyph rendering. Shaping relies entirely on existing OpenType features, so there is nothing to say about that in the spec, and nothing new to implement. An intern was able to design and implement most of this feature in a few months with no prior Gecko experience. (Thanks Edwin!)
• No way to mutate the glyph DOM, which simplifies implementation considerably.
• Full power of OpenType shaping available, including support for every script supported by OpenType, which is to say almost all of them. In theory this should also "just work" in fonts that use Graphite, an alternate, more extensible shaping engine for OpenType.
• Powerful ability to customize the stroking and filling of glyphs based on stroke and fill properties of the text.
• Fallback to regular OpenType glyph rendering for renderers that don't support SVG glyphs, and also if we need to obtain the outline of a glyph as a path (e.g. for <canvas> addText()).

We'll be working with other vendors like Adobe (who have a similar proposal) on the public-svgopentype mailing list to converge on a standard as soon as we can.

Thanks to Edwin Flores for doing the implementation work and Cameron McCormack for helping design the feature and write up the spec.

This (long) weekend our family took advantage of the perfect weather to take a road trip to Taranaki with the goal of me and the kids climbing Mt Taranaki. We did it, but it was very tough!

My kids are quite young and I knew this would be the most challenging hike we've ever done. In the interests of safety we took a lot of gear (more accurately, I did :-) ) --- including clothes for wet weather and for cold weather, lots of food and water, first aid kit, headlamps, and locator beacon. We started early around 7:15am and gave ourselves plenty of time.

The ascent went pretty well for a while. We made the Tahurangi Hut in about 1.5 hours, which is at the low end of the expected time. After that there's a path through a ravine (Hongi Valley) followed by some steps, which were no problem, but then there's a long scree slope and about halfway up it the kids started getting upset and wanting to turn back. I cajoled them through that section without too much fuss but the last section is a rock climb that took us about an hour and half, and they were really unhappy all the way up. It was tough enough for me with my fairly large pack, and coaxing the kids up as well was quite a struggle.

Once we reached the crater area everyone cheered up immediately. It was cold up there, but there was snow and lunch and knowing we'd made it made a big difference. From the hut to the crater had taken us a bit over three and a half hours, which was actually not bad at all (nominal times are from three to four and a half hours). I clambered the short distance to the actual summit which was great, but a bit anticlimactic since clouds covered most of the land around the mountain.

I had been nervously anticipating the descent: I don't like heights and I was not enjoying the thought of looking down the mountain all the time. Nevertheless once we got into it, it wasn't a problem. Our descent was very slow --- slower than the climb --- but steady and safe. It took us about four hours to work our way back to Tahurangi Hut, which was a lot longer than nominal, but not a problem. We got back to the visitor's centre car park at 6:45pm for a total of just under eleven and a half hours --- tired but happy!

If I had known exactly how challenging it would be, I'm not sure I would have had the nerve to do it. The encouraging comments of the trampers around me, both to me and the kids, really helped keep us going on the way up, and I'm very grateful for them. Honestly I was wondering on the way up whether I was doing the right thing by forcing the kids to carry on; fortunately now we all agree that I did :-). (I never thought we were in any kind of danger, other than the danger of regretting the entire trip.) Apart from enjoying the day, the kids are proud of their achievement, and rightfully so. I'm a big believer in earned self-esteem.

I spend a lot of time processing bugmail and looking at bugs. Interacting with bugzilla.mozilla.org is pretty slow, but I think it could be greatly improved, potentially saving me 15 minutes a day or more. Multiplied across our Bugzilla-using engineers and managers, that could be a large return on investment.

Every day (ideally) I read my bugmail using GMail. This is actually pretty fast. However I often need to load a bug's bugzilla page in the browser, either to re-read the context of a bugmail (earlier comments, or the contents of attachments or patches, etc), or to make changes to the bug --- usually add a comment, but sometimes change flags or other fields. I get bugmail on more than 50 bugs a day usually, and given I often scan my bugmail more than once a day, I reckon I might spend up to an hour on this on many days.

The problem is that loading a Bugzilla bug takes me about 5 seconds under the best circumstances and a lot longer for large bugs or busier networks. Also, every time I commit modifications to a bug I have to wait for about that much time for it to be acknowledged (one has to wait to ensure there wasn't a dreaded "mid-air collision").

Pretty much all that wait time is unnecessary and could be avoided with a different client. For example, we could have a Web app that does the following:

• Tracks which bugs have been modified since I last viewed them
• Preloads the complete data for those bugs
• Lets me instantly move from one bug to the next
• When displaying an updated bug, scrolls automatically to the first update that I haven't already seen
• Lets me make changes in situ
• When committing changes, instantly move to the next bug
• If there's a mid-air collision, alert me even if I happen to be looking at some other bug at the time
• Try to avoid mid-air collisions by receiving notifications of updates by other users while I'm viewing the bug

A client like this could make us a lot more efficient in the way we currently work. We'd probably also use Bugzilla differently and more effectively.

Two weeks ago we had our annual-ish Mozilla office outing. This time we spent two nights at Great Barrier Island, 90km northeast of Auckland.

"The Barrier" is more remote than most other islands near Auckland, and therefore less visited; I hadn't been there since I left NZ in 1994. However, it's well worth a visit. We chose to fly there on Friday morning on Great Barrier Airlines. The flight from Auckland domestic airport to the island takes about 40 minutes, gives you a spectacular low-flying view over Auckland and the Hauraki Gulf, and costs only $95. That's a great deal.

On arrival we checked into our rented accommodation --- two houses in Medlands Beach. They were nice. There's no mains electricity on the island but people make do with solar and generators; later we even met a guy who lives there doing 3D modelling work on his laptop. We all went for a walk on the pristine sandy beach and walked up the Sugar Loaf hill at the northern end. The beaches and general scenery on the Pacific-facing side of the island are just amazing. Later in the afternoon we drove (in rented 4x4s) to Tryphena and then Cape Barrier at the southern tip of the island, where it was blowing hard from the southwest --- quite spectacular, with waves crashing on rocks in glorious sunshine and few signs of civilization about. That evening we cooked our dinner on the house's gas-fired BBQ, and rounded things off with games of Settlers, Power Grid, and Guillotine.

Saturday was focused on getting everyone to the top of Mt Hobson, the highest point on the island. We drove up the Aotea Road to the eastern side of the mountain, and hiked through Windy Canyon to the summit. Needless to say, the views at the top are spectacular, but I was also impressed by Windy Canyon which I had not seen before (all my previous ascents of Mt Hobson were from Port Fitzroy). Some of our group returned the same way in the hopes of getting back to base early enough to go surfing (no luck, due to the westerly winds), while the rest of us continued south to the Whangaparapara Road via the Kaitoke Hot Springs, where we had a good soak. Our companions had thoughtfully dropped one of the cars there so we had no trouble getting back to base for a rest. The hardiest of us went for a swim in the ocean: it was still a bit too cold for comfort, but after vasoconstriction kicked in, the water felt lovely --- and it was so clear, floating around over the sand in the sun was delightful. In the evening we drove into Tryphena for dinner at "Tipi and Bob's Waterfront Lodge"; good food in a great location at the shore, especially with the westerly wind blowing in! That evening's game was Munchkin.

Sunday morning we cooked up the rest of our food, which was mainly burgers, for brunch. A couple of people in our group had earlier requested that I explain my "stance on religion" at some point, and after brunch I did just that. Of course, it was interactive, and not just a lecture. To me it felt like a pretty good discussion. Instead of talking about abstruse philosophy (much), or hot-button controversies tangential to the core issues, I was able to focus explaining the gospel --- about as clearly as I ever have before, I think. I think everyone involved actually enjoyed it.

After lunch we walked the southern end of Medlands Beach and then headed to Tryphena to catch the ferry to Auckland. I had been apprehensive that the strong southwesterlies would make the return trip very uncomfortable, but the Sealink ferry was fine --- for those not prone to seasickness, at least. Some of the group had trouble. As a consolation we did spot a few dolphins.

Overall our excursion was quite successful. Overnight trips are definitely a lot more fun than day trips, at least for me. They get harder to organize as our numbers increase, but I'll keep trying to do them as long as we can.

I recently spent two weeks in North America, which means two trans-Pacific flights and eight movies to watch. None of them were very good, but some were more interesting than usual for various reasons.

• Ted: A little more amusing than expected.
• Johnny English Reborn: Very low expectations, slightly exceeded.
• Savages: Quite good. Definitely reinforces my pro-legalization inclinations. Films like this make me grateful that, even though the stakes in my job are actually higher than most organized crime, we have to deal with considerably less kidnapping, torture and murder.
• Edward Scissorhands: I guess I'm not really a Tim Burton person.
• Total Recall: Not bad, but not special. Stick with the original.
• Painted Skin 2: Resurrection (Chinese): Nothing special, but I do have a soft spot for the genre.
• The Italian Job (original 60s version): I expected a regular caper film and got ... this. I certainly didn't see the ending coming. I don't know what to think.
• Alfie (original 60s version): Nothing induces self-righteous rage in me like an absolute creep being successful with women, and that's what this movie is largely about. As a movie I suppose it's not bad.

Every so often people ask me for advice on what to do when they visit New Zealand. This is hard to answer because there are a lot of wonderful opportunities here, and it's impossible to see all the "must see" places in just a few weeks. Also I feel a lot of the best parts of a trip are the in-between places, the serendipitous stops and turnings between the highlights. So my main point is to not even bother trying to knock off a list of "must sees". Plan a route that covers some of the known spectacles and take your time along it.

I suggest starting in the north (arriving in Auckland usually) and working your way south. On average things get slightly more spectacular in that direction, and it's better to move up that gradient.

In some parts of the world, the most popular attractions are "over-touristy" and to be avoided, but I think that's mostly not true here: I think most of the popular NZ attractions really are good.

Stay out of the cities, or if you're studying or working in a city, get out of the city as often as possible. I think most of NZ's cities are great places to live, but the best parts of New Zealand for visitors are outside them.

Here are some places I like:

• In the North Island, I really like the geothermal areas around Rotorua. My favourite one is Waimangu Valley.
• The central volcanic plateau of the North Island is one of my favourite places. A deservedly popular highlight is the Tongariro Crossing, a one-day hike across Mt Tongariro. The guided walk to the top of Mt Ruapehu is in some ways even better. Do them both :-).
• I took Mozilla people on the boat trip to White Island a couple of years ago. It's extraordinary and well worth doing. (You probably get the impression that I'm a huge fan of volcanoes and other geological activity. It's true.)
• If you find yourself with a day in Auckland, head out to Piha. If you wake up in Auckland, take the ferry to Rangitoto for the morning.
• In the South Island, Queenstown, despite being quite touristy, really is worth visiting.
• The Nelson Lakes National Park is great. A wonderful day hike up Mount Robert is one of the most memorable walks I've done.
• The train from Christchurch across the mountains to Greymouth (and back in the same day, if you want) is really spectacular. On one trip we stopped along the way at the town Arthur's Pass for a couple of days --- wonderful alpine area.
• Taking the ferry from Wellington to Picton is a great trip. It passes through the Marlborough Sounds which are lovely.

New Zealand has many famous multi-day hikes, if you're into that sort of thing. On these, people usually sleep in built huts rather than camp. I haven't actually done any of the famous ones myself, since my kids are only just getting old enough, but they get rave reviews from everyone I know. Most of the famous ones have to be booked in peak season. You can rough it or book more luxurious options.

Having said all that, I've left out a lot of incredible stuff, both things I've done and things I haven't. There's just too much. That's why I suggest instead of rushing from one highlight to another, plan an comfortable itinerary and take time to enjoy everything you see along the way.

One of the best things about living in New Zealand is that I get to take holidays here a lot :-).