I'm about to hit the road again. On Sunday I fly to California for a MoCo Gecko team "work week" to plan out the next Gecko update. That should be exciting. I'll actually be staying in California for an additional week to attend the Berkeley OSQ retreat in Santa Cruz on May 15-16. In between I'll be hacking away at the Mozilla office and hanging out with some of my local friends. On Wednesday the 14th I plan to visit Stanford to give a talk.
Lately I've been spending most of my time beating down the last Firefox 3 blockers. In the last few days I've been writing test infrastructure so we can have automated tests for key events generated by different international keyboard layouts. For example, pressing "α" on a Greek keyboard should be able to trigger shortcuts (e.g., the HTML accesskey attribute) labeled with "α" or "a". There have been some nasty late regressions in this area; it's very complex and there are conflicting user expectations. Behaviours vary by platform and locale and even within platform versions.
One problem I've run into is that I need to be able to use GDK's keymap APIs with a GdkKeymap for the keyboard layout requested by a test, but as far as I can tell you can only get a GdkKeymap for the current keyboard layout for a screen. Having automated tests change the actual keyboard layout for your X screen is something we really want to avoid since it will have nasty side effects, especially if someone is trying to use their machine while running tests in the background... It's unfortunate because both Windows and Mac have reasonable APIs for working with application-selected keyboard layouts.
On the side I've been doing a bit of work to speed up our SVG filter code, especially Gaussian blurs, which seem to be everyone's favourite filter demo --- for the next Gecko release, of course. It shouldn't take long and when I'm done I'll write up what I did and what else can be done for filter performance.