We noticed during development of Firefox Mobile that we were a bit larger than some other Android apps. We’ve written about why that is before, but one thing that’s eating up space in that little .apk file is locales. Android doesn’t let us filter what you download based on language (although they’ve started to add more options that way). So for our past few releases, we’ve put out a multi-locale version. At run-time, we look at which language your system is in. If we have it, we use it. Unfortunately, we can’t ship every language we support.

To get around this we’ve been working on a mechanism to let you download your favorite locale dynamically. Recently the last piece of this landed for users on our Nightly and Aurora channels to start testing. To turn this on, you need to point Firefox Mobile to a list of downloadable locales compatible with your version. Eventually, this will come from AMO, but I’ve put up temporary lists at:

• Nightly Build Users: http://people.mozilla.org/~wjohnston/nightly_locales.xml ( http://bit.ly/qgsFqF )
• Aurora build Users: http://people.mozilla.org/~wjohnston/aurora_locales.xml ( http://bit.ly/nBICkw )

To use these lists:

1. Open about:config
2. Search for the pref “extensions.getLocales.get.url” (it should show up if you search for “locales”)
3. Change the pref to one of the above links (now that we support copy and paste, it might be easier to just open them and copy and paste it from the urlbar).
4. You’ll have to restart Fennec for this pref to take effect (fixed in nightly – bug 689702)

Everything should continue like normal, but now when you go into our preferences section and select to change your locale, you will (after a second to download) see a list of downloadable locales. You can then pick the locale you want, click “Continue”, and the locale will be downloaded, installed, and set up for you automatically. Because these locales are actually distributed as add-ons, using them right now requires a restart of the browser (although we’re going to remove that soon), and voila! you should have Firefox  in the language of your choice.

The Update problem

There are some things to worry about here. Nightly builds of Firefox Mobile are not string frozen. New strings can appear or disappear from day to day, and if you’re using a locale with missing strings, that can lead to a completely broken version (aka the yellow screen of death). To help avoid this, we disable the installed locales each day before we update, and try to download a new version if its available. Aurora users shouldn’t be seeing string breakage from day to day (Aurora is string frozen), but this is the time we encourage localizers to start updating their locales, so Aurora users should see the same disable and update occurring each day when they update.

When this feature moves to Beta and Release builds of Firefox Mobile , we distribute updates through the Android Market. This means that our updater code never runs to disable and update add-ons, but because the locales are only marked compatible with one particular build of Firefox, they’ll be marked incompatible by the Add-ons Manager. To help keep this from becoming to annoying, we also try to update any locales marked disabled by the add-ons manager each startup as well.

The last few pieces of this just recently landed, and its time to start letting our Nightly and Aurora users beat on the feature to test it out. Feel free to use the above prefs and localization files, and try Firefox Mobile out in a new language. Find problems. Report bugs (or email me, or send us a message in the #mobile channel on IRC). If your language isn’t available, feel free to jump in and help! Help us make sure that Firefox is great for users on mobile devices in every language. Thanks!

Touchevents are necessary on browsers designed to be used with your fingers like Fennec. Our panning and double tap detection can make it difficult to forward typical mousedown, mouseup, and mousemove events to the client in a timely manner. For instance, in Fennec, we currently set the active pseudoclass on elements when they are first tapped (and use it for tap highlighting). If the user lifts their finger, without moving it very far from the initial mousedown, we wait a short time to make sure there isn’t a second (‘double’) tap, and if not we fire mousedown, mouseover, mouseup, and click simultaneously on the element. The delay makes it impossible to create pages that quickly respond to user input.

To help with this, in Fennec 4 we removed the time spent waiting for a double tap if the page has disabled user scaling in the metaviewport tag. This allows the page to quickly receive click events, but since we pan the page as your finger moves, we still couldn’t send mousemove events to the client. Touchevents provide the bridge between the two modes of interaction. Instead of registering for mouse events pages can register for touchstart, touchmove and touchend events. These seem very similar to typical mouse events, but have a few key differences. Touchevents don’t contain clientX/Y, pageX/Y etc coordinates directly on the event. Instead, the mouse coordinates are stored as an array of touchpoints and added to the touches property of the event. So, for instance, to use just the first touch or an event, you can call:

window.addEventListener("touchstart", function(aEvent) {
  var x = aEvent.touches[0].clientX;
  var y = aEvent.touches[0].clientY;
}, true);

In addition, touchevents also target themselves differently than regular mouse events. While touchdown is fired on the initially touched element, touchmove events will always remain targetted at that same target, even if the user moves their finger onto a different element. So if you want to write touchevents to drag an object around the screen, you can register a touchdown and touchmove listener on the object, and you will always receive the move events on the object, even if the user moves their finger onto a different element on the page. That’s how this example from quirksmode works.

When a page registers touchevents we attempt to detect it in the Fennec chrome and disable panning until the page has had  its chance to handle touchmove events. If the page author decides to call preventDefault on either touchstart or on the very first touchmove event, it will prevent Fennec from panning the page (we still allow panning the sidebars and urlbar off of the page, but will not allow you to pan them back on). It will also prevent any clicks that would normally be fired. This can pose a problem for Fennec where panning the page is necessary in order to gain access to the urlbar, and to the tab- and control-sidebars.

In order to continue to allow you to access the UI, and still allow pages to allow complex touchevents, we’ve currently implemented two escape hatches into Fennec:

1. Pressing the menu button will show the urlbar, allowing you to move to a different page
2. Pans starting at the very top of the page (within the top 1/2 inch) can not stop the panning of chrome

These will always bring in the chrome, and so you can trust that they are showing valid content.

Single-touch events are supported in nightly builds of Fennec (Android – other platforms) and should ship (fingers crossed) with Fennec 6. Support for multi-touch on Android is currently targeted at Fennec 7. Feedback is welcome. In particular, we’d like to ensure that turning these on hasn’t introduced noticeable regressions in panning for anyone, or if you can find places where our handling of preventDefault doesn’t agree with what is present in other modern mobile browsers. Test them out. Enjoy! Google Maps is likely the primary place where you will notice the work (NOTE: Maps has display problems partly due to scaling issues in Fennec, and partly because of Google’s use of webkit prefixed css without providing fallbacks for other browsers). I wrote a quick (and buggy) finger painting program to demo as well, but we’re excited to see what kind of nifty web applications and games people use this stuff for!

Special thanks to Matt Brubeck and Olli Pettay for their hard work within the WebEvents work group. Olli (smaug) also implemented the backend pieces necessary for Fennec to support touchevents. Matt has been hard at work documenting how touchevents work in different mobile browser (hint: they’re not all the same), and filing/fixing bugs to help us continue to bring Fennec’s implementation inline with as many as possible.

Valentines day is coming up, and I love my wife. Not a huge fan of the day myself. One year, for some reason we actually had to celebrate a few days after Valentines day, and happily the cost of everything she wants drops by 50% after the holiday. I’ve tried to make this a traidition, but it hasn’t quite caught on with her yet. Instead I think she would rather just celebrate twice. But like I said, I love her, so I’m gonna end this with a nice picture from when we were dating:

The pic above is from last weekend when we drove down the coast to see Big Sur. There’s a funny story there. Might as well write it to start this off. There is a beautiful waterfall down that coast at a place named Julia Pfeiffer Burns State Park. The park is really pretty, and there’s this really easy nice trail leading to this:

You can’t really see the waterfall here at all, but it’s there off to the left, spilling off that cliff and onto the beach, and then trickling into the ocean. We made it barely at sunset on a pretty cloudy day, and while it was super pretty for us, our camera isn’t that nice. So this is what you get.

The story involves us being late, and the fact that, just 10 minutes north of Julia Pfeiffer Burns State Park is Pfeiffer Big Sur State Park, a place that is quite different. Pfeiffer Big Sur is kinda pretty too. It’s a bunch of forest, some camp sites, and a Ranger station manned by an angry park ranger who spends more time chatting with friends than helping you out. It’s also got a few signs, but most of them don’t face the direction you’re facing, are tiny, and probably don’t contain the information you want. Some of them tell you that trails are closed, but don’t have maps. Those that have maps don’t have helpful, “You are here” stickers, so you really can’t read them anyway. Pfeiffer Big Sur is a place for those looking to frustrate themselves. And if you manage to survive the frustration and find the trail, at the very end you are greeting by a separate, also beautiful waterfall:

Frustrated and tired after a long walk to this place, we asked the manager of a gift shop where the waterfall was. We specifically mentioned that this waterfall flows into the ocean. I even mentioned the name of the trail it is on (“Easy Waterfall Trail”) according to a book. Unfortunately, I forgot to bring the tour book and picture of the waterfall, and instead she sent us back up the same trail again. Luckily, I”m not dumb and didn’t fall for this trickery. We then found out that I am also stupid and had typed the wrong name into our GPS during the original trick. Luckily all worked out. We had a pretty day, but also one full of reminders that good UX design applies far beyond consumer electronics and vehicles.