Great Barrier Island

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.

More Movie Reviews

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.

What To Do When Visiting New Zealand

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 :-).

Trouble Ahead For SVG Stacks (Maybe)

We have a large impending problem for CSS and SVG, and the solution may require breaking content using the "SVG Stack" image-bundling technique that's starting to become popular.

The problem arises because we want to unify support for images and SVG paint servers in CSS syntax. For example, we'd like CSS 'background', 'mask' and 'fill' properties to accept both SVG paint server values (e.g. SVG gradients and patterns), and CSS image values (such as CSS gradients and images). This seems like a significant improvement in both simplicity and power for Web authors.

The problem is that if we do this, then syntax such as 'background:url(foo.svg#abc)' becomes ambiguous. It could refer to either an SVG paint server element (such as a <pattern>) with ID "abc" in the external resource document "foo.svg", or an SVG image "foo.svg" in which we should make visible the element with ID "abc".

The obvious way to resolve this ambiguity would be to load the document foo.svg and check if the element with ID "abc" is an SVG paint server element. Unfortunately that is very difficult to do because we load external resource documents differently to SVG images and subject them to different constraints. For example, for security reasons external resource documents for paint servers are required to be same-origin with the main document --- in Gecko, at least, and we think the security reasons are good enough to require the same behavior in every browser. (Webkit hasn't addressed this yet because they don't support references to SVG paint servers in other documents.) On the other hand, we definitely can't disallow cross-origin SVG image loads. We really want to be able to determine the kind of load to perform before we start loading the document!

Relying on checking the kind of element a reference points to is also problematic if that can change dynamically. I don't actually know of a way that an SVG image or external resource document can cause the element referenced by a fragment identifier to change, but there are a lot of "near misses" --- for example, it would be possible if script was allowed to run in an SVG image or an external resource document, or if declarative animations could animate the 'id' attribute, or if we had a declarative Web feature for transclusions, or if <meta refresh> was supported in SVG images or external resource documents. If it turns out that the element referenced by a fragment identifier can change, then it doesn't really make sense to try to reload the document in a different way when such a change happens. (It might also be possible for the element referenced by a fragment identifier to depend on whether the document was loaded as an SVG image or an external resource document!)

Therefore I have proposed on www-svg and www-style that we inspect the URIs in a 'url()' value to determine whether to perform an external resource document load or an image load. A URI without a fragment identifier would be loaded as an image, but a URI with a fragment identifier that isn't obviously supposed to be part of an image (e.g. a Media Fragment URI) would have to be interpreted as a reference to an external resource document. This would work fine with almost all content out there, but would break SVG Stacks :-(. That is not good, but no-one has proposed a better solution yet.

If we do take this approach, we would probably have a workaround for SVG Stacks such as requiring them to use the "=" character in their fragment identifiers to make it clear the URI should be treated as an image load, not an external resource document reference.

I hope that this can be resolved at the upcoming W3C TPAC, since any solution needs concerted effort from browser vendors, and soon.

Motutapu Camping

This weekend was the first weekend of the school holidays so I took the kids camping. We took the 9:15am ferry to Rangitoto Island and got off at Islington Bay right near the bridge to Motutapu Island. We tramped with our gear along the Motutapu Walkway for two hours, including stops, to get to the campground at Home Bay on the east side of Motutapu, mostly through farmland. We spent two nights camped at Home Bay and then yesterday tramped back to Islington Bay along the road (taking about an hour) to catch the morning ferry back to the city.

The weather was good on Saturday and great on Sunday. It was rainy on Monday but that was fun in its own way --- I like being out in the rain if there's a good reason to be. On Sunday a ferry pulled into Home Bay with some day-trippers --- a group doing a walk as part of the Auckland Heritage Festival, and some volunteers doing weed control. The latter were part of a huge ongoing project to reforest a third of Motutapu. The island (along with Rangitoto) has been cleared of predators and colonies of rare birds --- including takahe and shore plovers --- have been transplanted to the island. Native fish and freshwater crayfish are also being reintroduced to the streams.

Like some other sites around the Hauraki Gulf, Motutapu has some old WW2 fortifications --- a number of pillboxes and gun emplacements. These have some tunnels that are fun to explore with a torch, and of course at the surface they have excellent views over the outer Gulf.

On Sunday we did a decent-sized walk from Home Bay up to the gun emplacements and then to Billy Goat Point at the northern tip of the island. Except we didn't quite reach the point, since the path led through a large paddock with cows. As we walked along the path, every cow that saw us started following us. After a while we all got a bit nervous and were wondering how we'd get back through the herd of about fifty cows that had gathered --- assuming they didn't decide to cause problems for us on their own! The kids were scared and I was rather nervous myself, but everyone did well and didn't panic. We turned back and just walked slowly in the direction we wanted to go. The herd surrounded us and moved with us and we didn't have any problems, but it was a relief to get over the stile to put a fence between us and the cattle. We completed our walk through Sandy Bay, Administration Bay, the Motutapu Outdoor Education Centre camp, and the road back across the island to Home Bay.

There wasn't a lot to do at the campsite but the kids had fun just being kids --- playing on the swing, fossicking on the beach, skipping stones on the water, smashing rocks, reading books, playing tag, that sort of thing. The campsite is huge and there were only three tents on it the whole time we were there. Overall it was a great weekend away, highly recommended.

Karekare

Nine days ago we took our research intern out to the west coast. In a change from our usual Waitakere destinations, we went directly to Karekare beach, walked south through the dunes into Whatipu (passing the tramline tunnel), inland at the Paraha valley, and then back to Karekare through the hills along the Zion Hill track. It was excellent, although the Zion Hill track was quite muddy. The whole walk took about four hours.

It's probably a little better to do the loop in the other direction, to get the up-and-down stuff out of the way first. We did the beach first because I hadn't been that way before and maps warn that it might not be passable at high tide. But either those warnings only apply during a big storm, or the dunes have grown since those warnings were written --- it didn't look likely that a high tide would cut off the path. So next time I'd definitely take the Zion Hill track first if the weather's reasonable.

Web Audio In Firefox

Let me clear up any confusion about what our plans are for audio APIs in Firefox.

Some MediaStream support has landed in Firefox 17. We have the ability to create MediaStreams containing the output of media elements and use them as a source for other media elements. I need to make some changes to those APIs based on feedback we start evangelizing them for real. We can also create MediaStreams via getUserMedia (when that feature is preffed on in about:config).

The work on MediaStreams Processing that I did as an alternative to the Web Audio API is on the back-burner. Our priority is to implement Web Audio. Our plan is to implement AudioNodes using the same infrastructure as MediaStreams under the hood --- to reduce code duplication and to ensure that Web Audio/MediaStreams integration is perfect. Some core infrastructure for MediaStreams that are produced by processing inputs to outputs --- ProcessedMediaStreams --- already landed, to support the features above. Currently Ehsan is working on the IDL/DOM API side and I have some more work to do on the MediaStreams infrastructure side. We don't have a specific date set for Web Audio support, but it is a high priority.

At some point we will revisit MediaStreams Processing to get the features that Web Audio is missing, e.g., seamless stitching together of an audio and video playlist from a series of clips. That is lower priority.

Blast From The Past

I haven't sung this song for years, but Gen, bless her, brought it back on Sunday. Stuart Townsend nails the important points in a moving and personal way.

How deep the Father's love for us,
How vast beyond all measure
That He should give His only Son
To make a wretch His treasure.

How great the pain of searing loss,
The Father turns His face away
As wounds which mar the chosen One,
Bring many sons to glory.

Behold the Man upon a cross,
My sin upon His shoulders;
Ashamed I hear my mocking voice,
Call out among the scoffers.

It was my sin that left Him there
Until it was accomplished;
His dying breath has brought me life
I know that it is finished.

I will not boast in anything:
No gifts, no power, no wisdom,
But I will boast in Jesus Christ
His death and resurrection.

Why should I gain from His reward?
I cannot give an answer.
But this I know with all my heart
His wounds have paid my ransom.

Granularity Of Import Directives In Programming Languages

Look at any C/C++ source code in a large project and you'll see a lot of #include directives at the start of each file. Even in more modern languages like Java, C# and Rust, each file starts with a list of import directives.

These directives are a form of boilerplate code that rarely convey anything useful to human readers. For small files, they can occupy a significant fraction of the file. They have to be maintained by developers. They can cause merge conflicts.

On the other hand, they have some practical benefits. Import directives can be used to resolve ambiguities: when the same name occurs in two different scopes, import directives can be used to map the name to the desired definition. Another benefit is that declaring dependencies explicitly can make it easier to view and track dependencies, and prevent undesirable dependencies. Also, explicit dependencies reduce the problem of new definitions for a name changing the meaning of existing code.

Here's a proposal to capture most of the benefits, and greatly reduce the costs:

• Make import directives per-module instead of per-file or per-translation-unit (except in rare cases where a particular file wants to use a name defined in multiple modules). This lets developers observe and constrain dependencies at the module level, which seems to be all we need.
• Support labelled versions of a module's interface and allow import directives to import the names in a given version.
• When importing between modules in the same project, use wildcard imports that import all public identifiers. When importing from an external project, import a particular interface version. When modules are in the same project --- by which I mean they belong to the same version control repository and are built and tested together --- adding new definitions to a module won't cause latent problems for other modules, so there is no need to protect against that via import directives.

Unfortunately, you can't do those things in C/C++ --- at least, not without penalizing compilation time by creating omnibus header files. In new languages with more modern compilation models, you could. I wonder why it hasn't been done.

A Confession Of Sorts

Reading this LWN article about sexual harassment at conferences led me to another story that was even more compelling and instructive. Read it now or the rest of my post will be unintelligible.

I identified strongly with "Dr Glass" and would have behaved almost exactly the same. But I would have been hiding something, which means Dr Glass might have been too, as far as any observer in the story could know, and I think that adds another layer of implications to the story.

The secret is that I would have been attracted to Luminous Girl, and though I would have successfully suppressed it in my behavior, it would have been hard work. A superhuman observer might notice me glancing at her a little more often than necessary; on a bad day I might even have lustful thoughts about her. This would taint my motives for protecting Luminous from the Awkward Guy: as well as being the right thing to do, it would be fun to live out the fantasy of the Heroic Protector Of The Attractive Woman. Thus, Awkward Guy's mistaken assessment of Luminous as Dr Glass' possession would not be completely off the mark.

Does any of that matter if observable behavior is unchanged? In the Christian worldview, it certainly does, since God looks at the heart. But I think even many materialists would think differently if they knew or suspected what was really going on inside Dr-Glass-as-me.

I would have done one thing very differently from Dr-Glass-of-the-story: I love hiking, but there is no way in the world I would go for a hike alone with an attractive teenage girl I barely know. There is a small possibility of disaster: not rape, but if she made advances, I can't be completely sure I would pass that test --- mainly because I have never faced such a test, and I don't want to. Anyway, the solution is simple: bring a third person along.

Attention NZ TV Sports Interviewers

When interviewing athletes after an event, I want to know what they think, not what you think. So, why are you always making statements and inviting the subject to agree with you? Instead, ask open-ended questions.

Bad:

• "It was tough at there for the last twenty minutes, wouldn't you say?"
• "It looked like you were completely calm at the start?"

Good:

• "What was the toughest part of the match?"
• "How did you feel at the start?"

Same goes for any other kind of interview, but sports interviewers irritate me the most.

In-Flight Movies

Picoreviews (including last month's trip to Beijing)

• Wrath Of The Titans: Blah.
• Puss In Boots: Surprisingly good. Better characters, plot and action than your average action movie.
• The Great Magician: Good. Mixed tone, but interesting and fun.
• Chronicle: Good.
• John Carter: Blah.
• Contagion: OK. Not best watched on a plane next to someone coughing.
• The Invention Of Hugo Cabret: OK. A bit too much "look, a movie about movies, isn't this clever".
• Mission Impossible 4: OK. Utterly generic but well done at that.
• Salmon Fishing In The Yemen: Technically proficient, but it focuses on a protagonist whose marriage isn't very good so he runs off with a younger woman. I don't find that heroic, so I don't sympathize with the narrative thrust and the movie simply does not appeal.

Recently in theatres I've seen The Avengers (really good), Prometheus (good in every way except that it makes absolutely no sense --- what a missed opportunity), and The Amazing Spiderman (good in every way except that it's a retread of a ten-year-old movie that was perfectly good the first time around).

North Head To Takapuna

Yesterday, after church we wanted to do something outdoors (again) since the weather was spectacular (again), so we did a bit of an urban adventure. We took the ferry to Devonport, walked up North Head for the amazing view over Auckland's harbour and the Hauraki Gulf, and watched a documentary there about the project to eradicate predators from Rangitoto and Motutapu islands (which is now complete!). Then we walked to Takapuna via Cheltenham, Narrow Neck and Takapuna beaches. Between beaches we could have walked around the rocky foreshore since the tide was far out, but to save time we took the streets instead. We reached Takapuna around dusk, rewarded the kids (and me) with ice-creams and took the bus back to the city, where we had Korean food at Nol Bu Ne restaurant. That place is really good --- cheap, tasty, and filling.

Tawharanui

This weekend my family visited Tawharanui Peninsula. It was a brilliant winter's day --- cool but not cold, perfectly sunny, with a light breeze and amazing visibility; we could see distant islands that you can't normally see from this region. We walked from Anchor Bay along the North Coast and Tokatu Point tracks to the end of the peninsula, then back through the bush via Fisherman's Track to Anchor Bay.

It reminded me a lot of the other Auckland peninsula parks Shakespear and Duder (also highly recommended, although I think Tawharanui tops them :-) ).

Muriwai

A couple of weeks ago on a lovely winter's day our family drove out to Muriwai for a walk. I can't remember going there before although I might have visited in my childhood and forgotten. We'd been to all the other easily accessed beaches on the west coast of the Auckland region, but not this one. I was a bit surprised to discover that Muriwai is probably the most easily accessed of them all --- less than 40 minutes from downtown Auckland. I guess that's because you don't have to traverse the winding roads of the Waitakere Ranges.

I think it's just a little less spectacular than Whatipu or Piha, but still lovely. Between October and February the gannets are nesting at their colony, which must be amazing, so we'll have to go back then.

Bolo

Bolo was a popular Mac multiplayer tank battle game back in the early 90s (predating the Web!). I played it a good deal in the computer science grad lab at Auckland University. It's probably the most fun multiplayer game I've ever played. The core gameplay was quite simple (it had to be, on that era's hardware), but team strategy and tactics got very deep and games would often get very intense. It didn't have the problem that has turned me off RTSes --- an initial "rush phase" that usually decides the game in the first five minutes. Skilled players could turn around an inferior position, but it mostly avoided endless see-sawing too.

I've been looking for classic games to play with my kids and yesterday I decided to see what had happened to Bolo. The original Mac version is long gone but a clone, Winbolo, was written for Windows and ported to Linux. It was shareware for a while but now it's been released under the GPL. There is actually no downloadable Linux client --- the port was not maintained --- but in a few hours of hacking last night I was able to bring it back to life. The gameplay feels great, closely matching what I remember.

Winbolo would be a great game to port to the Web. It's tons of fun, multiplayer, open source, and not very demanding on the client. The only difficult part (but it's a biggie) would be networking. Winbolo is client-server using UDP. You could use Websockets but that wouldn't be ideal. What we really need is WebRTC datagram support. Fortunately, that's coming!

Computer Science In Beijing

The actual point of me being in Beijing was to give a talk at ISMM about memory management in Web browsers, to attend the PLDI and ECOOP conferences and some of the associated workshops, and to talk to CS researchers about all the things I'm interested in.

My ISMM talk was on Friday morning. I felt my delivery was a bit rough because it was all new content for me, but people seemed enthusiastic. I talked about some of the unusual constraints of browser development, such as having to optimize for both perceived performance as well as real performance (unusual for academic researchers, that is). I gave an overview of how we manage memory, with particular emphasis on the cycle collector and some of the optimizations we're doing with it. And I talked quite a bit about Memshrink. I tried to give a lot of credit to Nick Nethercote and others who did the actual work. I've uploaded the slides.

Many ISMM people were very interested in our use of reference counting. There's a paper by Rifat Shahriyar, Stephen Blackburn and Daniel Frampton at this year's ISMM on optimizing reference counting; its motif is that tracing GC has totally defeated reference counting and no-one uses reference counting in "high performance systems", but they will get reference counting "back in the ring". It's a very good paper but their motif is a bit misleading, since in fact reference counting is heavily used in large C++ applications, especially browsers, which we like to think of as high-performance systems! The disconnect is that academic research on reference counting has almost totally focused on memory management for Java virtual machines and similar systems, so what they meant by "high performance system" was "high performance safe-language runtime". Furthermore I realized that there's a critical difference between reference counting in most C++ apps and reference counting for JVM heap management. In the latter case it's generally assumed you don't know which objects are shared across threads, so every refcount update must be an atomic operation, which is incredibly expensive. But in Firefox we statically know which classes can be shared across threads, and in fact we know that most objects cannot, so most of our refcount operations don't need to be atomic and are therefore much cheaper. Thus most of the research results on reference counting do not directly apply to us. However, it would probably still be a good idea for us to mine the literature for good ideas to try --- Richard Jones apparently has a good survey book out, and we should look at Erez Petrank and Steve Blackburn's papers. (Let's not forget David Bacon, whose work inspired our cycle collector in the first place!)

There's a lot of academic research on Javascript. There was very little about compilation at these conferences, other than Brian's PLDI paper on type inference. But there are a lot of people doing static and dynamic analysis of Javascript, doing various tweaks to the language, exploring semantics, etc. That's good.

There's a real explosion in record-and-replay research. That's encouraging, although it's also a bit annoying because very few people are working on the precise problem I care about. A big theme in research these days is "PARALLELIZE ALL THE THINGS", so most of the record-and-replay research is about finding ways to record and replay shared-memory parallel programs, which Firefox isn't really yet. There are some cool ideas there but what we really need is a low-overhead easy-to-deploy record-and-replay system that doesn't depend on anything difficult such as code instrumentation or static analysis or heroic post-facto constraint solving, and we're willing to stick to a single core to get it ... but it's not clear who's working on this, except us with rr.

A related problem is a new instance of a common pattern: in order to carve out space in an area that's getting crowded, researchers are starting to make up interesting variations on record-and-replay to do research on --- variations that probably will never be relevant to real-world problems. I met some researchers trying to record the activities of particular objects, which I don't think will ever make sense if we get the ability to record a whole process at low overhead.

My friends at IBM presented their paper on Race Detection For Web Applications. This paper applies happens-before race detection techniques to detect a page's incorrect dependencies on the ordering of event dispatch. It's a great start, but there's a lot more that can be done to reduce false positives and to create a deployable tool.

One thing they and a lot of other researchers need is an instrumentation framework for Javascript in the browser. In Java there are well-known techniques for instrumenting bytecode to do all sorts of cool dynamic analyses, and the VM also provides lower level hooks like JVMTI. We need something like that for JS. Shu-yu Guo did a nice presentation of Mozilla-based tools, including Jason et al.'s Debugger object at the JSTools workshop, and it occurred to me (and not only me, I think) that it would be really great to extend Debugger with the ability to replace a script with an instrumented version. We already have a lot instrumentation points via DOM events and XPCOM observers, so just adding Debugger-based script instrumentation might be enough to build some really amazing tools, such as the aforementioned race detector.

Amer Diwan gave an interesting keynote about methodological flaws that endanger CS research results. I took the opportunity to ask a question about the bias coming from our reluctance to publish negative results. That week I heard about a few interesting projects that could have worked but didn't, where knowledge about why they didn't would be really valuable to the community. I harp on this regularly; I don't know if my nagging is going to have any effect, but if I ever have the chance to organize a workshop, it'll be the Workshop Investigating Negative Results ("WINR!").

I spent a lot of time talking to Leo Meyerovich. His work on synthesizing parallel layout engines from high-level descriptions is excellent. I used to think it could never scale to handle real CSS, but these days I'm rather more optimistic.

Overall there was a lot of interesting work, and certainly a lot of interesting people, but nothing really blew me away with "how could that possibly work!". Still, an excellent trip.

Google Plus Spam

Recently I removed Google+ from my Google account. Unfortunately, people are still adding my account to their Google+ circles. (I had assumed they wouldn't be able to do that anymore.) Worse, I now get an email every time they do that. The email has tiny text saying "To change what emails Google+ sends to you, you can always manage email subscriptions on the settings page." with a link. When I click on the link, guess what happens? It goes straight to a "Join Google+" page with no way to turn off the emails (unless I rejoin Google+ I guess) :-(. It's odious.

I'm still getting emails from Linkedin too. These sites are like malaria, once you've had them they're incurable.

Experiencing Beijing

There were some surprises. The weather was great --- hot, but the famous smog was barely noticeable and we had clear blue skies much of the time. On seven of the eight days you could see the mountains around Beijing; apparently this is unusual. There was a lot more English signage than I thought there would be --- not just for major services such as the subway system, but almost every street sign, many shop signs, and many menus all had English (or at least names in pinyin), and not just in major tourist areas but everywhere I went. It was easier to get about without language skills than I had expected.

I managed to cram in a good deal of sightseeing. I had two free Sundays that I spent roaming around. On the first I was alone and walked from the hotel to around the Olympics area --- the Bird's Nest Stadium, the Water Cube, and the vast plazas between them. It was a beautiful day and lots of people were out sightseeing or flying kites. I took the subway downtown, and walked around the Forbidden City and nearby hutongs --- old streets that preserve the character of centuries of urban living in China. It was all most impressive. (I took the subway frequently all through my trip, as it's easy to find one's way around the system and saves dealing with taxi drivers. It's also ridiculously cheap --- 2 yuan (about 40c NZ) to go anywhere I wanted to go. Obviously Beijing's high population density and low labour costs help, but I wonder if it pays for itself.) I returned to the hotel and went out for dinner nearby with some students, to a cheap but clean local restaurant with food that was simple but novel to me, such as spicy stewed chicken and some unidentified cucumber-like vegetable, cold in a tangy sauce. By the end of this day I already felt much more comfortable; I had stopped feeling self-conscious at being the sole white person in an environment, and I'd adjusted to the traffic behavior in Beijing. (It seems that any driver or cyclist can do anything at any time if they think they can get away with it.) I'd also become used to brushing aside people on the street who accosted me. I wonder what they would have said had I stopped to listen, but my curiosity did not overcome my caution.

During the six days of conferences I only went out in the evenings, for dinner. On Monday night I went with other students to a dumpling house. The dumplings were cheap and tasty but I've had better. Tuesday night was the PLDI banquet at an art gallery in the 798 art district. 798 is a gentrified industrial area (on a large scale, as everything seems to be in Beijing). In fact it feels a little self-consciously bohemian to me, but it certainly was interesting to walk around. The food at the PLDI banquet was a range of delicious finger-foods and I had a great time even though the setting, and big parties in general, aren't really my thing. On Wednesday night I went with a group to a night market downtown, but I wasn't feeling 100% (something I'd eaten earlier, not sure what, disagreed with me) so didn't end up eating anything there. Judging by the smell, that might have been a good idea under any circumstances, although the non-olfactory atmosphere was great to experience. On Thursday I went out with a professor friend to meet his family at the tiny hotel they were staying at in a hutong in a different part of town. This was a classic Chinese house arranged around a central courtyard. We ate at a tiny place nearby, tasty cheap local food at a makeshift table on the street, perfect! Friday was the ECOOP banquet, back in 798 but this time a sit-down meal in a converted factory with the sawtooth-style roofing that is characteristic of the area. On Saturday evening a local Beijing student volunteer took a group of us to Nanluogu Xiang, a famous hutong (near Houhai). We walked the main street, which is mostly shops now, and ate at one of the cafes there. The street, and the cafe, were rather touristy, but we were on the roof and had a great view over the neighbourhood, so it was lovely.

I was fortunate to be able to spend all of Sunday with one of my closest friends. We booked a car and driver for the day and went out to see the Great Wall at Huanghuacheng. Just traveling out there was very interesting, as our driver took some back streets and I finally saw the countryside outside Beijing: dusty, intensely cultivated in chestnut trees and corn, farmers drying crops on the road, run-down villages, strange three-wheeled pickup trucks, and despite the roads being less crowded, even more insane traffic behavior than I'd seen in the city. Huanghuacheng is an interesting place to visit the Wall, since it crosses a river there via a dam, but apparently it's less frequently visited than some of the other parts. We walked along the wall up and down a couple of hills for three hours: slow progress due to the extremely steep slope (hands-and-feet in places) and areas of disrepair. It was very hot: the temperature must have been around 40C and there was little shade. The glue holding the cheap plastic cover to my cellphone melted. Oddly, people on the dam were constantly letting off fireworks: mortar types much more powerful than I've seen in civilian hands before. From Huanghuacheng we went to the Ming Tombs area and visited the tomb of the Yongle Emperor at Changling. It has similar architecture to the Forbidden City, but smaller and in a completely different setting. We also we walked along the statue-lined "spirit way" at the entrance to the Ming Tombs complex.

I think building a massive funereal edifice for oneself would be a grave sin --- it's a monument to one's vanity with a side order of blasphemy --- but it does have the redeeming feature of leaving an artistic legacy for future generations, with luck. It also shows a refreshing acceptance of one's own mortality, which is certainly better than the delusions of immortality (both grand and wilfully blind) that are so common.

On Sunday night my friend and I visited a restaurant near the hotel that served somewhat fancy cuisine from northeastern China. This was a great place: an 86-page menu with lots of interesting dishes and drinks. The most interesting dish we ordered was fried silkworm pupae, which tasted disgusting. Everything else was very nice.

Overall the food during the trip was very interesting and tasty, and I'm glad to have had it, but often the ingredients seemed a bit bland. I think we're lucky to have high-quality produce in NZ.

My visit provoked lots of thoughts about geopolitics and the Chinese people, but mostly trite so I'll keep them to myself. I will say that the Great Firewall is much more painful than I'd realized. Lots of sites I use simply didn't work and although most of the bustage was presumably the Firewall, one of the worst aspects is that you can't easily tell when it's the Firewall, which makes diagnosing problems very frustrating. In some cases the Firewall seems to break only some pages in a given domain, or otherwise make random features on particular pages break or be very slow.

Overall I had a wonderful time and I'd love to go again. As in Europe, I get an enormous thrill just wandering around places where people have lived for thousands of years, and in many ways China's history is even more intriguing. However, I am very glad to come home, and to live in New Zealand.

Of course, the actual point of my trip wasn't sightseeing but to attend PLDI, ECOOP and workshops, give my ISMM invited talk and do a lot of talking about computer science with all the people there, many of whom I know well from my research days. But this blog entry is already far too long so I'll defer reporting on that to another post.

To Beijing

I'm planning to be in Beijing next week. I've been invited to give a talk at the International Symposium on Memory Management 2012. It's colocated with PLDI, ECOOP and various workshops --- a key destination for my former colleagues in computer science research --- so I'm looking forward to hanging out with a lot of old friends and a few other Mozillians. Hopefully I'll learn something about what's going on in the field, too. Although I'll probably be stuck in the hotel most of the time, I will have some time to see a bit of Beijing and I'm very much looking forward to that as well.

I should have some connectivity but the onslaught of computer scientists is expected to crush local Internet service, so I don't expect much!

Leaving Linkedin

Inspired by others, I just quit Linkedin. There was almost no value in it to me --- probably negative value to due to having to deal with their email. I am now a member of zero social-networking sites, which I find very satisfying.

The City And The City

I've just finished reading China Miéville's The City And The City. It's amazing. The premise is original and outrageous, and seems hard to sustain given he places it in the context of the real world, but he carries it through brilliantly. I've previously read his Bas-Lag novels; they were very good (if flawed); this is much better. Not only do I think it's a better book, but it doesn't creep me out the way Bas-Lag does.

Mangawhai

This weekend was Queen's Birthday Weekend so we got Monday off. The weather was excellent the whole weekend. On Saturday my family went to Mangawhai Heads (about 1.5 hours drive from Auckland) and did the Mangawhai Cliffs Track. We walked up the beach, around the rocks to the headland, then up the hill on the track, through the bush and along the clifftops back to the beach and carpark. It was dazzlingly beautiful and a good reminder that although people here like to complain about the weather, having such brilliant and warm days in winter is one of the great blessings of the Auckland region.

The Canvas getContext() Mistake

The HTML <canvas> element has a getContext(type) method that takes a string parameter identify a context type (e.g. "2d" or "webgl") and returns a context object of that type. The string parameter was introduced as an extension point to make it easier to add new context types.

This was a mistake. It would have been simpler, and just as extensible, to define a new attribute on the <canvas> element for each new kind of context. E.g. canvasElement.context2d, canvasElement.contextWebGL, and even experimental vendor-specific contexts such as canvasElement.mozContext3d. Less code to write, slightly more efficient, and easier feature detection. (If some contexts need parameters, or we consider getting a context to have more side-effects than is seemly for an attribute getter, we could have used independent methods instead, e.g. canvasElement.getContext2d().)

Of course we're stuck with getContext now for Web compatibility. The reason I mention this is because from time to time I see people trying to use getContext() as a model for extensibility in other Web APIs. Don't do that.

Actually, most of the time when I see someone trying to use getContext() as a model, they're using it because they think it gives them an escape hatch from the world of Web standards. They seem to think that it would be OK to pass in vendor-specific strings, get back vendor-specific objects, and never specify or even document the behavior of those objects. This is incorrect. It's no more acceptable to have permanently non-standard Web APIs accessed through vendor-specific strings than it would be to have them accessible through vendor-specific attributes.

Firefox Vs The New York Times

For several months I've noticed that when my Firefox session gets bloated, about:memory shows zombie compartments associated with the nytimes.com site. I don't visit that site very often, but over a week or three a small subset of the pages that I visit there are leaked. I worried about it but didn't know how to track it down. It's hard to debug problems that arise over a period of weeks. (It's a testament to the reliability of our nightly builds though!)

Yesterday and today I discovered that by clicking around a large set of nytimes.com pages I could reproduce the problem in a reasonably short amount of time with a fresh profile and a small set of tabs open. Furthermore, with about:ccdump and some help from Olli Pettay, I was able to identify the particular element which forced the cycle collector to keep everything else alive. The next step was to figure out where we added references to that element that the cycle collector didn't know about. It's a hard debugging problem because we don't know which element is the problematic element until long after the references have been added

I tried a few approaches but tonight I finally found a successful one. I made a Windows full memory dump of the errant Firefox process, and attached to it with WinDbg. In the still-running Firefox process I then used about:ccdump to identify the address of the leaking DOM object. I was then able to use WinDbg's "s" command to search the entire memory space for occurrences of that address. Then I had to identify each occurrence. For the references the cycle collector knows about, this is easy: about:ccdump reveals the addresses of the referencing objects so you know those memory areas will contain the address of the leaking object. For other occurrences I had to dig around in nearby memory to figure out what sort of object contained the occurrence. Sometimes it's easy because there's a nearby vtable pointer and WinDbg can tell you which class the vtable pointer belongs to (using the "ln" command). Other cases were trickier. For example I found a reference to the leaking object next to a reference to an XPCNativeWrapper, in what looked like an array of similar pairs, and guessed that this was part of the hash table that maps DOM objects to their JS wrappers.

Anyway, I finally identified two references to the leaking DOM object from inside an nsFrameSelection object. These references were buried inside a copy of an nsMouseEvent that nsFrameSelection keeps for obscure reasons --- and did not tell the cycle collector about. Having identified the problem, creating a fix was easy since we don't really need to keep that copy around at all. Hopefully it'll land soon.

WinDbg has awful usability but is quite powerful and can do useful things that Visual Studio's debugger can't. I'm a bit fond of it as the distant descendant of DEBUG.COM and SYMDEB.EXE, which I spent a lot of time with while reverse-engineering and patching MS-DOS binaries (i.e., stripping copy protection from games) in my misspent youth. Too bad the syntax hasn't improved over the years!

Crosbie's Hut

Around this time last year I took my children to the Pinnacles hut and since then I've wanted to take them on a similar trip again. The Auckland region doesn't have many huts suitable for a one-night overnight tramp --- the Waitakere and Hunua Ranges, and Gulf islands, have many good campsites but no huts --- so I set my sights on Crosbie's Hut, in the same general area as the Pinnacles, near Thames on the Coromandel Peninsula. Unfortunately it's been difficult to get away --- weekends have been very busy, or the weather forecast has been poor, or the hut's been fully booked! This weekend we finally made it.

We entered at the Tapu-Coroglen Road, a bit more than two hours' drive from Auckland, where a track heads south to meet up with tracks from the coast at Te Puru and Waimoa and then to Crosbie's Clearing and the hut. I chose this route because I thought it might be a little easier to start higher above sea level, and because I thought walking across ridges might be less muddy than going up the valleys. It was still rather muddy! I sank in up to my knee at one point which caused some anxiety in the group. The nominal time from the road to the hut was 4 1/2 hours and we took almost exactly that each way. It's very much a tramping track, not a walking track and there's a lot of up-and-down.

We had a wonderful time. The weather was great, mostly very clear, and the hut is quite new and very well designed. The trampers arriving before us had started up the hut's wood-burning heating stove which was much appreciated. The view from the hut is superb and omnidirectional. To the west you can see the Firth Of Thames, to the east Whitianga and the Pacific Ocean. The night sky was scintillating.

One delight of bringing the kids is the interest and approval shown by other trampers. I guess it's not very common for kids as young as mine to be taken tramping, but the older trampers think it's great that I'm passing it on! (Though I'm not really passing it on, I'm learning myself!)

The other trampers at Crosbie's were all very experienced so I asked them a few questions. Most huts collect rainwater in tanks, and the Department of Conservation officially encourages people to boil or treat water used for drinking, but I haven't seen anyone do that yet. One guy I asked said he's never treated water at any of the DoC huts he's stayed at (even when taking it from a stream) and nothing's happened to me yet". Hmm.

Accelerated Scrolling In Firefox: Past, Present And Future

Scrolling performance is always important and we've made some pretty huge strides since Firefox 4. It may be helpful for me to explain some of what's happened.

In Firefox 3.6 and earlier, we had some pretty complicated code to analyze every scroll operation and figure out if we could safely scroll by just blitting some region of the window to another place and repainting the rest of the affected area. (In the very old days this was done in nsViewManager; later it was done using frame display lists.) This was quite difficult to do; for example an HTML <textarea> has a solid white background behind the scrolled text, so to prove that you can just blit the text, you have to determine that there is a solid-color background underneath the entire scrolled area. But the real problem was that it would quite often fail and we'd end up repainting the entire scrolled area, or most of it. For example, a large position:fixed element would require us to repaint the area around it. A background-attachment:fixed background would require us to repaint the entire window. This was bad because it meant scrolling sometimes "fell off a performance cliff".

In Firefox 4 we overhauled scrolling to use the new layer system. The basic idea is very simple: while scrolling, you put the content that's moving into one set of layers, and the content that's not moving in other layers. To scroll, add a translation to the transform matrix for the moving layers, repaint any parts of layers that have scrolled into view, and recomposite the window. If we do that properly, we'll never have to fall back to the "repaint everything" path; scrolling will just "always be fast". It also integrates cleanly when scrolled content uses accelerated layers for <video> and <canvas> etc.

This being the Web, there are of course a lot of complications. Separating moving from non-moving content is not easy. The infamously complex CSS z-ordering rules mean that even when scrolling a single element, you can have moving content interleaved with non-moving content so that you have to have two or more layers for each.

When you place content in these separate layers, the layers can become difficult to render. In particular text using subpixel-antialiasing placed into a moving layer, where its background is not moving, needs to be stored with separate alpha channels for each color channel ("component alpha"). This is difficult to implement efficiently. With GPU-based compositing we use shader tricks, but with CPU compositing it would be too expensive so when we encounter this situation we back off and stop caching the text in a retained layer and just draw it every time we composite the window. However even with CPU compositing, we still win on a lot of pages that use position:fixed or background-attachment:fixed.

Another thing that makes layer-accelerated scrolling difficult is when scrolled content is subject to some effect from its ancestors. The most common difficult case is when an element combines non-'visible' 'overflow' with 'border-radius' and must clip its descendants to a rounded-corner rectangle. The best way to handle this is to add support to the layer system so a container layer can clip its descendants to the rounded-rectangle border-box of an element. Until recently we didn't have that, so scrolling inside such elements was forced to repaint everything, but Nick Cameron just landed a large project to add that capability to layers and to use it in all kinds of rendering situations, including when scrolling. That means in a scrolling element that's clipping to its border-radius, the scrolled content is rendered to retained layer buffer(s) as if there was no border-radius, and then we clip to the border-radius during compositing (very efficient with a GPU since we cache the border-radius shape in a mask texture). (Nick's project provides other benefits such as accelerated video and canvas inside containers clipping to their 'border-radius' without hitting nasty fallback paths.) Summary: in Firefox 15, scrolling inside an overflow:hidden/auto element with border-radius gets a lot faster.

There is of course more to do. There are still CSS and SVG container effects we don't handle: namely filters, masks, and clip-path. Masks and filters need more layer-system support (especially filters!). Once those are done, then at least with GPU acceleration enabled it will be very difficult to hit any slow "repaint everything" paths when scrolling. (Although it's already very rare to see scrolling content inside a clip-path, mask or filter.)

The other pending important scrolling improvement is asynchronous scrolling, i.e., the ability to trigger a smooth scroll and have it happen immediately at a constant frame rate without jerkiness, even if the thread running the Web content is blocked due to Javascript execution or whatever. We've already developed most of this for Mobile Firefox (and B2G), but it needs to be made to work on desktop as well, which is not trivial. It requires enabling asynchronous compositing on all our platforms, and teaching the compositor a bit about scrolling. Once that's done, because we're able to layer-ize scrolling in almost every situation, we'll be in extremely good shape.

Sad And Pathetic Machines

On Saturday I visited a friend’s house to see if I could help them with slowness problems on their home computer. This was a six-year-old machine running XP with 448MB RAM. I observed that on startup Windows Update would run and while running, pretty much all the RAM in the system was consumed by Windows, wuauclnt.exe and svchost.exe (which assists Windows Update). During this time, starting Firefox or IE took minutes; the machine would thrash itself senseless. This state lasted for quite a long time, about half an hour, probably exacerbated by my attempts to get stuff done. Once it subsided, Firefox started quickly and ran well.

This is apparently a known problem and some kind of Microsoft regression.

Under these conditions, Firefox startup time and other metrics are bound to be awful.

Update I forgot to mention, but the Microsoft malware checker was also running at the same time as Windows Update and contributing significantly to resource usage. I guess it checks the downloaded and installed updates for malware...

Korea

A former colleague of mine from IBM is now a senior executive at Samsung and offered to have them sponsor me in a visit to Korea, to talk about mobile Web browsers and Tizen. I thought it would be interesting, and it was.

The main part of my time there was Monday, when I spent nearly all day giving presentations of my thoughts on various aspects of Mozilla's mission and work:

• Mozilla's mission in the mobile Web era --- mostly the same as my talk in Sydney last year.
• Architectural overviews of various Mozilla products.
• Overview of our layer compositor framework.
• A discussion of 2D drawing APIs, and why we're doing Azure.
• Parallelism in Web browsers: what we're doing and what else could be done.
• A retrospective on XUL and browser extensions, and my thoughts on the future.
• Mozilla's work on open Web apps and app stores.
• Security models for open Web apps.
• BrowserID (borrowed from Francois Marier).
• Rust, Servo, the need for a new browser engine and the extreme risks of building one.

Samsung's campus in Suwon is quite fabulous and their people were very good to me.

However, the most interesting part of my trip was Tuesday. I got up before 6am and made my way to Seoul to pick up a tour of the North Korean border area. This tour stopped at Imjingak park first, then Infiltration Tunnel #3. This is a tunnel North Korea dug under the border, later revealed by a defector --- one of four found so far, but up to twenty are speculated to exist. It's made for short, non-claustrophobic people. Walking 500m hunched over is no fun, but the place is amazing.

After the tunnel we visited Dorasan Station, just outside the DMZ. It's a very impressive and almost entirely symbolic train station --- there's nothing around it, it symbolizes the desire to keep the train line running north into a unified Korea. A passionate desire for unification among many South Koreans was evident. Our tour guides spoke forcefully about Korea's troubled history in the 20th century and their desire to see a unified and independent Korea reemerge. (Our first guide was quite frank about the atrocities of the Japanese colonial period, which was a bit awkward since there were a lot of Japanese tourists on our bus.)

They had a North Korean refugee with the tour to talk first-hand about the horrors of life in the North. I've read some of the stories of refugees and defectors, and those stories make me sad and angry, but actually meeting a refugee was mostly humbling. This was a middle-aged woman who'd escaped across a frozen river on the Chinese border in the middle of winter, and then for two years worked her way to South Korea through China, Laos, Vietnam and Cambodia, on the run from the authorities the whole time --- just a few years ago.

The best part of the tour was the Joint Security Area. That's the village right on the border where soldiers of both sides are stationed and where officials meet. There have been all kinds of crazy incidents there (check Wikipedia), and I find it incredible that they allow lots of tourists to visit it. You can stand close to the border and take pictures of the soldiers and buildings on the other side (but not the south side!). You can go right into the building where officials meet, where the border runs right through the table in the middle of the room, and even walk around the table to the North Korean side. (The North Koreans and South Koreans have a sort of protocol for taking exclusive access to the building for their tour groups.) While we were in there, there was a group of North Korean soldiers right outside the building windows, inexplicably taking photos of each other posing in front of the border. Towards the end some of them took photos of our group through the window, no more than an arm's length away.

There are all kinds of interesting facts associated with the DMZ and JSA, too many to go into here. I'll mention that the South Korean guards stationed at the JSA border are the best of the best --- must have a black belt in taekwondo or judo, university education, speak a foreign language, sufficiently handsome, sufficiently tall, parents not divorced, etc. While tour groups are present, they stand completely motionless and silent in carefully designed poses. Wearing dark sunglasses, in immaculate uniforms, they all look identical. Some people had their photos taken standing next to the guards in the meeting room (but not too close, we were repeatedly warned). It's surreal.

In fact the whole scene is surreal. I find it a little disturbing that the elite soldiers of perhaps the world's most repressive regime, and the contested border they guard, have been turned into a tourist attraction. I suppose we should hope it stays that way. At various points I prayed that before too long the border will be a relic, as is the Berlin Wall.

I got back to Seoul around a quarter past five, and learned something else about South Koreans: they work hard. Samsung had sent a car to take me back to their Suwon campus for a few more hours of meetings. It didn't bother me, since I wasn't going home to my family that night anyway, but a fair number of people were still working by 9pm, and I was told that most of them had arrived early that day. Impressive work ethic, and I suppose it's a partial explanation for South Korea's remarkable rise, but I think a bit unbalanced for healthy family life.

I really enjoyed my short visit. I found the country fascinating, and the people were very friendly and polite. I was surprised by the amount of English signage; even a little snack shop in Seoul had English I could point to to order. All the food was excellent --- now I finally have some idea of what real Korean food is like :-). I have to say though, that living there would not be attractive to me; the landscape is too relentlessly urban, and I cherish my New Zealand lifestyle.

The Internet Experiment Has Failed

I'm worried about the Internet. Not about the usual Mozilla stuff, although there's a lot of challenges there too. I'm worried that the Internet, the way we use it, is bad for people; bad for individuals, and bad for society.

One reason is security. We do not have the technology to build systems with strong behavioral guarantees; there are always bugs, and always exploitable bugs. The contest between attack and defense is vastly asymmetric; defenders must get everything right, attackers only need to find a few mistakes. Yet we keep bringing more of our world online. Even keeping systems away from the Internet becomes infeasible as mobile Internet-connected devices become increasingly pervasive.

Another reason is our brains. It seems obvious to me that the Internet is a lousy medium for human interaction (beyond people you already know well). There are lots of negative effects at work, and better-informed people than I have much to say about them. "Filter bubbles" are one concern. The accessibility of support groups for every kind of dysfunction (e.g. pro-anorexia or racist groups) is another. My biggest worry is the lack of empathy we experience when interacting with others online. The online comments of almost any major public Web site are toxic, especially on controversies. I've behaved badly online in ways that I never would have in "real life". In the incoming direction, the core Mozilla community is great, but random abuse and conflict from the Internet takes its toll. There's a lot more to be said about what's going wrong, but suffice it to say I'm an optimist about different kinds of people being able to get along in real life; I'm a decided pessimist about them getting along online.

(Even while I'm writing this, Christian Heilmann has posted about problems on Twitter.)

Let's not even talk about privacy and oppressive actors.

I'm fed up with techno-optimists who claim the march of progress is inevitably beneficial and we're just having some teething problems. Techno-optimists had big dreams for the Internet; that it would bring people together (see people yell at each other on Twitter), that bad information would be cured by more good information (see filter bubbles), that all knowledge would be universally available (OK, they got something right; thanks for Wikipedia). Not good enough.

So what should we do? For security, we need to increase the distance between important systems and the Internet. We need to steer towards technologies with provable properties (and somehow escape our dependence on C/C++ code). But that's weak sauce and I don't see our way clear. Human factors will let us down and there are hard limits on technology.

The human interaction problem is even tougher. Maybe we can find technical solutions to reengaging empathy. Providing voice and video interaction everywhere might help; WebRTC could save the world! (Probably not, but we'll try.) Individuals can opt to reduce their online presence and refocus on offline relationships. To some extent that's what I try to do, and in a low-key way I'm discouraging my kids from being online and engaged with computers (mainly by giving them more interesting alternatives).

What about the mass of humanity? Do we just keep accelerating and hope everything works out? Do we form a neo-Luddite action group and sabotage the Internet? Do we figure out some alternative approaches to using the Internet that limit the damage? I wish I knew.

Retrospective On Our Trip To Europe

When I'm traveling I try to avoid spending too much time moving from place to place. I want to spend enough time in each place I visit to get a feel for it. My goal for this trip was to get a bit of a feel for London, Paris, and rural villages in England and France. In England we chose Willersey in the Cotswolds, and in France we chose Lutzelbourg in Alsace (well, technically Lorraine).

It all went very well. We had only a few days of rain in more than three weeks, pretty good considering it was winter. It was good to alternate city with rural, because the days in the cities were hectic. In London I visited Imperial College for the ECOOP PC meeting, the Mozilla office, friends in Highgate, the Museum Of London, St Paul's, Westminster Abbey, the Monument, the Science Museum, the Victoria and Albert Museum, the Eye, and a lot more. In Paris, Notre Dame, the Eiffel Tower, Versailles, the Mozilla office, and the Arc de Triomphe. In the Cotswolds we explored Oxford and took a day trip to Warwick Castle, and otherwise rambled around the countryside, visiting the villages for Broadway, Snowshill, Stanton, Saintbury and thereabouts. From Lutzelbourg we walked to Pharlsbourg and Saverne, and took a train trip to Strasbourg.

Like most of our holidays there was a lot of walking and eating, hopefully waistline-neutral. We tried to eat local, of course, although it's not clear what that means in London. Food at inns in the Cotswolds was very good. We had a particularly memorable lunch at the Mount Inn in Stanton, in the middle of a long loop walk from Snowshill past Buckland and back; we were a bit tired and grumpy and the lunch cured everything. The Alsatian food was quite Germanic, unsurprisingly, and enormous.

It was the first time I have encountered really old cathedrals. I recalled the passage in The Mythical Man-Month where Fred Brooks points out the incredible self-discipline and humility required for a hundred-year building project; what it takes for generations of artisans to submit to the vision of an architect long gone. Those qualities are inspiring.

We attended an evensong service at St Paul's. It was a nice touch that they had separate seating for tourists and worshipers.

We attended an Anglican service at the parish church in Willersey. It's a great old church, dating back over eight hundred years. The congregation was mostly ancient too, and the sermon I felt was weak, but the people were most welcoming. We went to a French Catholic service in Lutzelbourg, which had much better demographics and was very lively. I couldn't understand a word of it but my translator said the sermon was informed and Biblical. Oddly though, when the service was over everyone left immediately with no fellowship.

Even where the people of God aren't doing well, I find it invigorating to see what he's done and is doing in different places and throughout history. Sometimes when I travel I'm lazy and don't bother going to the local churches on Sundays; that's a big mistake.

A great thing about Lutzelbourg and the Saverne area is the number of ruined castles. We explored the Château de Lutzelbourg just a short walk from the village, and Greifenstein near the road and canal to Saverne. Greifenstein has been abandoned for over five hundred years and looks exactly like I imagined a ruined castle should.

I'd certainly like to spend more time in Europe, but it also made me appreciate what we have here in Auckland, and it's good to be back.

Wakaraanga Creek

One of the things I love about Auckland is its diverse collection of parks and reserves. Since we moved back from New York (several years ago now!), on weekends we have regularly set out to explore unvisited green spots on the map. We're still finding great new places relatively close to home. This is due to many factors, including having so much coastline (Auckland straddles an isthmus), the many cones, lakes and other features of the Auckland volcanic field, and moderately enlightened urban planning.

Today we discovered the Rotary Walkway of the Wakaraanga Creek reserve at Farm Cove near Pakuranga. It's a paved path in coastal reserves along the Wakaraanga Creek and the Tamaki River. The weather was excellent, and the reserve and the estuary are delightful.

According to the local government's newsletter, the walkway around Orakei Basin has been refurbished, so that will be a good place to visit soon.

A couple of other tips: if you live in Auckland and haven't been to Rangitoto recently (or ever), or you visit Auckland, take the ferry to Rangitoto and make sure you visit the lava caves. It's an amazing place right on our doorstep. If you've done Rangitoto and the other popular Auckland spots, try Mangere Mountain. It's one of Auckland's best-kept secrets.

I'm Back

This morning we returned from our big European adventure. I don't have time to write a lot about it here, at least not now, but want to let people know that I should be back to my normal schedule. Just a few quick stream-of-consciousness points about the trip...

Mozilla London and Paris offices were great. Met some old friends and some new ones. Thanks.

Got ensnared in a few crises while away --- Planet Mozilla, H.264, DRM. One a week probably isn't much above average.

Fantastic weather given it's winter over there. Only a few days with rain.

Enjoyed what I thought I'd enjoy. Ruined castles are fantastic. Near Lutzelbourg it seems like every other hill has a ruined castle on top.

Being in places where people have lived for hundreds or thousands of years gives me a thrill.

Movies on return flights:

• Rise Of The Planet Of The Apes: quite liked it.
• Tinker Tailor Soldier Spy: loved it. Love the source novel(s), this is a great adaptation. Haven't seen the Alec Guiness mini-series, must track it down.
• Tower Heist: nonsense.
• The Headhunter: Norwegian noir-ish thriller. Quite good, let down by ending.
• Sherlock Holmes 2: surprisingly good at what it is: modern action-adventure in Victorian setting loosely inspired by Conan Doyle characters (I love the original stories). Like the first, enthralling set design ... loved the construction of the Underground going in the background.
• The Help: Read the book, thought this was a good adaptation and a good movie --- both generally moving in parts. Can't shake the feeling that the point of the book is a bit undermined by its author not being black herself.

Air France just about bungled our return trip, with our flight from Paris to LAX stuck on the ground for nearly two hours with a mechanical fault, causing us to miss our Air NZ connection from LAX to Auckland. But they made up for it by rebooking us on a Qantas connection to Auckland while we were over the Atlantic, without us even asking, and providing an assistant to push us through LAX with maximum possible speed to maximise our chances of making that connection --- who was happy to run with us between terminals. (Our incoming flight landed 1 hour 40 minutes before QF26 was due to take off, and just 50 minutes before boarding was due to start. We got to the gate in 45 minutes, which is certainly a record for me. We were just about stymied when, just as we reached the head of the "express" immigration queue, the systems supporting biometric checking went down, freezing admission for all non-US-passport-holders. After several minutes of confusion, apparently the "port director" authorized admissions without biometrics until the system came back up. Phew.)

Loved visiting Europe, but we're all so glad to be home. Had to climb a volcano today even if it was only Mt Eden.

Retro Movie Showcase

I only just now found out about the "Retro Showcase" going on in Auckland!

Fortunately it will still be going on when I get back. In order of priority, I would like to see

• It Happened One Night
• Gone With The Wind
• The Apartment
• Black Narcissus

Of those, I've only seen Gone With The Wind. Many of the others are good films that I've seen but don't need to rewatch.

Requiring Planet Mozilla Content To Be Mozilla-Project-Related

Like Taras, I think planet.mozilla.org content should be related to the Mozilla project.

Personally I like reading other community members' non-Mozilla content, but I recognize that many (most, probably) other people expect planet.mozilla.org content to be Mozilla-related (regardless of fine-print disclaimers) and I think that's a reasonable expectation. Looking at it slightly differently, Taras' request for an aggregated feed of Mozilla-project-related posts is very reasonable, and planet.mozilla.org is where people will start looking for it, so that's where it should be.

FWIW, after migrating from Moveable Type to Blogger and discovering that gave me the ability to send only Mozilla-tagged posts to planet.mozilla.org, I did just that, starting in January. If you want to read my non-Mozilla-related content, please subscribe to my blog feed directly.

I'll be writing something there shortly about my ongoing holiday in Europe. Currently I'm watching rats run around Fontaine des Innocents in Paris :-). And wondering why my Android phone suddenly can't connect to a WiFi network it was connected to an hour ago, which my laptop is using just fine :-(.

Movie Overdose

We arrived in London safely and just a little behind schedule. No matter how frustrating aspects of air travel can be, I never cease to be amazed and grateful at how easy and cheap it is to travel halfway around the world in a little over twenty-four hours.

As usual I spent most of the time watching movies and some TV.

• The Debt: Interesting.
• In Time: Intriguing premise, decent execution.
• Boy: Quite good.
• Network: Exceedingly dull and overwrought.
• Man On Fire: OK execution of routine material.
• Mural (weird Chinese film with female spirits who don't understand men (this is a genre)): Difficult to evaluate.
• The Night Watch: Not bad.
• A Shot In The Dark: Tedious (like all the other Clouseau films).
• The Big Sleep (1946): Brilliant. More great dialogue than all the other movies put together.

This movie binge reminded me how wrong mass media is. Based on movies, you would conclude that the most common occupation is "professional assassin", that outbreaks of violence and murder tend to be ignored by the authorities, that there are no happy marriages, and that there are no Christians (barring the odd exorcist or villain). I fully understand that movies focus on the abnormal because it's more interesting, and that most people can distinguish fiction from reality, but I'm too much of a pessimist to imagine that our unconscious assumptions are perfectly firewalled from our movie and TV diet.

Upcoming Travel

Our whole family is going to Europe soon. We're planning to leave Tuesday night (Feb 21) and return March 17. I will be mostly not working, and mostly offline, but expect to be checking email regularly and able to respond to some review requests and the occasional crisis. I'm planning to visit the new Mozilla London office on Tuesday February 28 and the Paris office on March 9 so I should get some work done on those days.

Foo Camp, ECOOP, And Conferences

I've just attended another marvelous Foo Camp in Warkworth. As always, it was a great opportunity to meet people doing interesting things who are mostly in New Zealand. One interesting attendee this year was Dave Dobbyn, who I didn't get to talk to, but I was very pleased to hear him introduce himself as "follower of Jesus".

I do feel a bit drained after each Foo Camp. It's not so much the late nights, but the effort required to talk to people I don't know very well. Wandering around trying to figure out who might want to talk to me or which conversation group I should try to break into, I feel socially inept. This is all fine, since talking to people who are doing strange but cool things I know nothing about is one of the best things about Foo. I do, however, find other conferences easier --- conferences that are related to Mozilla, or academic computer science conferences where I can expect almost everyone to share my interests.

Speaking of computer science conferences, I've just finished reviewing my share of the papers for ECOOP 2012 --- I'm on the program committee. It was quite a lot of work but it has been very interesting. It's encouraging to see how much research attention is being given to Javascript and browser-related problems nowadays.

Just recently, the PLDI 2012 accepted papers list came out. I was very pleased to see that Brian Hackett's paper on his Javascript type inference infrastructure was accepted. It's great to see cutting-edge technology actually shipping in browsers being recognized by the academic community.

I'm also glad to see "Race Detection for Web Applications" was accepted. For a long time it's been obvious that Web applications make unwarranted assumptions about DOM events firing in a particular order, and when those assumptions are violated you often get nasty nondeterministic bugs. This is the cause of a lot of the "random orange" test failures we see on the Mozilla test farm. For a while I've thought it might be possible to adapt well-known techniques for dynamic data race detection in multithreaded programs (where I did research, once upon a time) to find these bugs in single-threaded, but nondeterministically event-driven, Web applications --- and nagged researchers to look into it. Now Manu, Julian, Martin and Boris have looked into it and have shown that this can work. I hope I can take credit for suggesting the problem to Manu; however, an under-appreciated fact of CS research is that good ideas are a dime a dozen and the hard work is all in problem selection, implementation and evaluation. So congratulations to Manu et al. for breaking new ground and hopefully kicking off something that will result in more robust Web applications and less "random orange"!

To put the icing on the cake, I am very lucky to have been invited to give a keynote at ISMM 2012. It's in Beijing in June, colocated with PLDI and ECOOP over a whole week! I'm really looking forward to attending these conferences and catching up my former (and some current) colleagues, and actually seeing the presentations of the above papers.

Alternatives To Supporting -webkit Prefixes In Other Engines

Since news spread that the non-Webkit browser vendors are moving towards supporting some -webkit-prefixed properties, lots of people are pushing back with alternative suggestions, for example Daniel Glazman. Many of these are good suggestions, but here's why they won't work for the properties like transitions, animations, and transforms already in wide use:

• Evangelize Web developers to not use prefixed properties on production sites. This is swimming upstream against trends in Web development and market forces. At every Web dev conference I've been to, on almost every Web dev site (including browser vendor's own sites), Web developers are encouraged to use vendor-prefixed properties. Web developers who refrain will lose business to Web developers who don't. Ergo, not going to happen.
• Evangelize Web developers to use prefixed properties with "all browsers' prefixes" (sometimes automatically through preprocessing tools or even CSS extensions). This would help in some ways, but despite us browser vendors and a large chunk of the Web dev community pushing this approach for a long time, even with tool support, Web devs don't do it consistently enough. Even when we specifically contact big, clueful sites we have a good relationship with (like Google) to get this fixed, we often don't succeed. So I don't think one more passionate (angry?) round of evangelism is going to make the difference. Of course evangelism can't help with sites that are no longer actively developed.

  This approach has a big downside, too: it can severely limit the usefulness of prefixes in the first place. As soon as one browser implements a feature with given syntax, Web content can start assuming all other browsers use the same syntax and semantics, which forces those browsers to behave exactly as if the feature had been deployed unprefixed in the first place --- especially when Web developers include the unprefixed syntax as a "fallback" in case prefixed support is removed. Even if we could succeed at the evangelism, with this approach we might as well have not used prefixes in the first place.

• Teach Web developers not to rely on vendor prefixes by dropping support for them once standard versions exist. Webkit people have already said they won't do this. Furthermore, it encourages Web developers to go the "all prefixes plus standard name" route for everything they do, which makes prefixes pointless, as explained above. Doesn't help with deployed content anyway.
• Ignore the problem and hope that it goes away without us having to do anything distasteful. Um.

Some of the suggestions for things we could do in the future are good, like disabling experimental features in browser releases, but they won't help us out of the current situation. Maybe I'll discuss them in another post.

Note that trying alternatives that end up failing will have a huge cost to the open Web: it will delay the onset of a multi-vendor mobile Web, which is critically needed for the open Web to survive. I hate having to support -webkit prefixes, but "desperate evangelism while the problem gets worse, followed by supporting -webkit prefixes" would be even worse.

Meanwhile, to the people who think the solution is for Mozilla and others to just "work harder" at evangelism, or implementation, or standards work --- I cast aspersions in your direction. You have no idea how hard we work. I personally have never worked harder in my life, and I know that's true for many other Mozilla people. We hire more people, but the workload increases even faster. Meanwhile, Apple won't even hire a single full-time standards editor to help their proposed CSS properties reach standardization, which is a large part of what got us into this mess in the first place.

The Problem With Counting Browser Features

css3test.com is doing the rounds. I get almost exactly the same results in Firefox trunk and Chrome Nightly (64% vs 63%). This gives me a chance to explain why this sort of testing tends to be bad for the Web, without sounding whiny and bitter :-).

The root of the problem is very simple, and explained right at the top of the page:

Caution: This test checks which CSS3 features the browser recognizes, not whether they are implemented correctly.

Thanks for the disclaimer, but it doesn't eliminate the problem. The problem is that whenever someone counts the number of features supported by a browser and reports that as a nice easy-to-read score, without doing much testing of how well the features work, they encourage browser developers to increase their score by shipping some kind of support for each tested feature. Because we have limited resources, that effectively discourages fixing bugs in existing features and making sure that new features are thoroughly specced, implemented and tested. I think this is bad for Web developers and bad for the Web itself.

If Web authors reward Web browsers for superficial but broken support for features, that's what they'll get.

Instead, I would like to see broad and deep test suites that really test the functionality of features, and people comparing the results of those test suites across browsers. Microsoft does this, but of course they tend to only publish tests that IE passes. We need test suites with lots of tests from multiple vendors, and Web authors too. (Why haven't cross-browser test results for the official W3C CSS 2.1 test suite been widely published?)

I don't want to come across as harsh on css3test.com. The site is lovely, it has that disclaimer, and it goes a lot further than, say, html5test.com in terms of testing the depth of support for a feature. So it actually represents good progress :-).

Mozilla Tree Adventures

Last week we had a few overseas Mozillians stop by the office on their way back from linux.conf.au. We took the opportunity to hold our annual Mozilla Auckland outdoors event, which for only the second time ever did not involve volcanoes. Instead we went to Tree Adventures out in Woodhill Forest. Basically you strap on safety gear, climb ladders into the trees (up to 14 metres above the ground) and conquer a variety of obstacle courses on wires from tree to tree. Flying foxes are also involved. It's tons of fun, unless you have a fear of heights as I do, in which case it's tons of fun mixed with just as much sheer terror. I was glad to be able to overcome my instincts and keep going; that sort of mental discipline is worth practising. I just hope none of my colleagues noticed me whimpering.

We followed up with a nice lunch at Hallertau.