To enable, just open Settings -> Privacy and change the “Title Bar” pref to “Show page address”. We’ve also set up domain highlighting like you see on desktop Firefox (for both regular and private tabs show above, with or without Personas enabled, although Personas are a nice security measure for our new scroll away urlbar too!). Enjoy!

Splendid Apps

Twitter has a pretty awesome web app that showcases a lot of what makes the web great. The webapp is designed to work well on small screen devices (needs some work on tablets), and makes use of indexedDB to store data and startup up quickly, as well as including visible throbbers (since webapps have no browser chrome to tell users what is happening) and heavy use of AJAX to load content in the background. They’ve used touch events to implement a nifty pull-to-refresh implementation, have a nice fixed position header to provide easy navigation for the site, and use history apis to make it easy to navigate back and forward between “screens” of the app. If you’ve enabled posting with your location, they’ll use Geolocation to identify where you’re tweeting from. The version of the site they send as their app currently is only lacking support for photo uploads, but they work well if you visit http://m.twitter.com in Fennec (i.e. I assume they just haven’t been uplifted to the webapp yet). In short, its pretty awesome, easy to install, updates faster and more often than apps, and its safe! I’d highly recommend it to any of our Aurora/Nightly users. You can install it straight from the Firefox Marketplace! Or just bookmark the website on your Android desktop by loading it in Firefox for Android, long tap on the urlbar, and select “Add to Homescreen”.

Exquisite Hacks

For those sites that are… lets say less enlightened… the great thing about Firefox for Android is you can make the web what you want it to be! Writing extensions that extend or change sites is not much different than writing the same extensions for Desktop! Not long ago, a version of Stylish was even written that works on Firefox for Android, and today I threw up a style on userstyles.org that adds a much needed fixed position header to Facebook.com.

Learning Stuff

Unfortunately, Facebook users still can’t upload photos from the webapp. Facebook currently shows our users a message reading “Sorry, the browser you’re using doesn’t support uploading photos” along with a sell for their Android app. To be clear to our users, this isn’t true at all! To all the web developers out there who don’t know, Firefox for Android already supports taking photos right from web pages! All you have to do is add a file input with an accepts attribute set to “image/*”. i.e.

<input type=”file” accept=”image/*”>

You can also use “audio/*” or “video/*” for audio and video uploads respectively (I’m looking at you YouTube!).

I’ve looked into Facebook a bit and it looks like they’re depending on some proprietary api’s (opening a special fbrpc: url) they created for their native apps. Fixing this is definitely doable but is non-trivial hacking that would be fun for someone looking for a fun addon to write! Happy to help anyone interested.

I’ m hoping to keep this up for the next bit, calling out sites or apps that are doing a great job on mobile, and continue to point out things other authors can do to make their mobile pages better. If you know of any you’re especially impressed with, send ‘em my way.

One of the main things people really want (better integration with the Android launcher and Android app management stuff) is going to be tough to do. We’ve talked about doing things like dynamically building apk’s and even signing them on a Mozilla server somewhere. That opens up enough other cans of worms that we haven’t had time to chase yet. Stability and speed are our first priorities.

Thanks again!

WebApps run with their own profiles and in their own processes, like real native apps. They add desktop shortcuts. Show up in the Recent Apps lists. And they have access to pretty much everything you see on Desktop Firefox (including Canvas, CSS Transitions and Animations, and WebGL) + some shiny extras like orientation support. (Android security measures prevent putting them in your Android Launcher or modifying the correct App name/icon in the recent apps list.)

At this point, we need testers!

Testing:
Our teams eyes aren’t enough to hope to find all the problems or test all the devices out there. If you just love the open web and want to try these things out, testing is easy! File bugs (or yell in IRC, email me, reply here, or just tweet at me (DigDug2k)). Install. Start them. Quit them. Restart them. Switch between them. Uninstall them.

We need to know what works, what breaks, what you love and what you hate. There’s a Test Day tomorrow (8/24/2012) if you want to help. We’ll have an irc channel set up, or you can pop in to #mobile. BUT, you can test any time! In fact, I’d love users to keep using these things and to get some testing over more prolonged use. Some quick ways to install apps:

1. The Mozilla marketplace isn’t quite open yet, but is available to registered Mozillians. You get their either by going to http://marketplace.mozilla.org in Firefox Beta for Android, or through the Apps Manager (Android Menu -> Apps -> Click the shopping bag in the top right).
2. Since the market is still under active development, I put together something I call “Mini-Market” for testing as well. It contains a few curated apps that we consider ready for testing. If you’re interested you can play with it at http://bit.ly/minimart (WARNING: You will find bugs!). If you’ve got a great app you want me to add, drop me a line here. I’ll try to blog more about it in a bit.
3. Alternatively, if you run a site that is a webapp, you can serve up an app the through the apps API all by yourself. Trust me, no one enjoys huge “Install our Android App!” banners thrown in their faces when they’re trying to view your site, but I wouldn’t be surprised to see users using a well placed (not intrusive) “One-Click Install” button!

Writing an app:

There’s a lot to write about WebApp development (Note we don’t have to write Mobile WebApp because its pretty easy to write a webapp that runs well on all sorts of devices!). That’s a different blog post But I have noticed a few tips from testing a lot of apps:

1. Use metaviewport. It won’t affect your site on desktop. It makes things usable on mobile. Use it!
2. Along with that, now that your site isn’t being rendered at desktop sizes on phones, you can use media queries for responsive design too! And Firefox has a pretty awesome Responsive Design tool built in. The mini market uses some really simple ones to give a two pane view on tablets/desktop and a one pane version on phones.
3. Webapps have no chrome around them. You are responsible for showing progress if the user clicks a link or does something slow. Use XMLHttpRequest if you can. Plus, that should make it easier for you to build your own cache of responses and make your app super responsive. Desktop apps do it. Webapps need to start doing it too.
4. If you do load content dynamically into a single page, use the history API! All Android phones have a back button, and this makes it work!
5. Use App-Cache. I need to get some data here, but completely unscientific testing on my half with really bad mobile networks has shown apps taking 10-15 seconds to start, most of which is waiting on the network. The few (a.k.a. the one admittedly simple) app I’ve seen using App Cache is much faster.

Once you have a simple app built. Installing it is easy. You just to create an app manifest. There are some instructions and boilterplate for doing that here. The test manifest builder is also helpful if you want some boiler plate. Its mostly a simple JSON file you need to serve from the same host as your app. You can submit that manifest to the Mozilla Marketplace (or any other store’s that appear) if you want to use it for discoverability, or you can give users a link to install it from your site by simply calling

navigator.mozApps.install(“path/to/manifest.webapp”)

Thats about it. Happy testing! Once again, please provide us feedback however you can. We’re listening and we’re anxious to make the web a first class citizen for apps.

Sidenote to try and avoid questions: Our users also don’t get some other nice Google Maps features like pinch-zoom and nice looking buttons. We fully support multitouch touch events in Firefox for Android, and pinch zoom works (last I checked) if you change your UA to match the stock browser or iPhone. The CSS problems are mostly due to the use of -webkit-background-size without other vendor prefixes. If someone wants to port Stylish to Fennec, it’d be a start to a prettier Google Maps experience for many of our users!

The Maps devs at some point realized they had all this nice code written to handle mouse events for their setup, and wanted to reuse it as much as possible. Ideally, touchevents and mouseevents would be interchangable and things would just work, but this is the system we’re kinda stuck with now. So the Maps team built functions that take touch events, convert them to mouse events, and rebroadcast them:

var sendConvertedTouch = function (eventType, touchEvent) {
  if (1 != b.changedTouches.length) return k;
    var mouseevent = document.createEvent("MouseEvents"),
             touch = b.changedTouches[0];
    c.initMouseEvent(eventType, true, true, window, true,
                     touch.screenX, touch.screenY,
                     touch.clientX, touch.clientY,
                     l, l, l, l, 0, null);
    c.translated = true;
    touch.target.dispatchEvent(mousevent);
  }
}

I doubt this is crazy performant, but it works! I’m guessing there are similar hacks all around the webs. This makes sending mouseup/down/move events simple.

It takes a bit more work to actually fire clicks when the user taps. There’s numerous tools and utilities out there to help with these things. But in this case the team decided to do their own thing. A super simplified version of the result looks something like:

var dragging = false;
document.addEventListener("touchmove", function(event) {
  dragging = true;
}, false);

document.addEventListener("touchend", function(event) {
  if (!dragging)
    sendConvertedTouch("click", event);
  dragging = false;
}, false);

(in their case, dragging actually holds a count of the number of taps).

This fails in current builds of Fennec. Why? Well essentially we don’t do a whole lot of filtering on the input we send to content. The system sends us a touch event, we send it on to content (we do some event coalescing if our internal event handling/drawing is slow the entire system doesn’t get backed up, but that’s about it). But touches on a screen actually jitter quite a bit especially on hdpi devices. Even when it feels like your finger is completely stationary, you’re probably still sending tons of touchmove events to the pages you’re viewing. So even though your finger hasn’t moved far, we send a touchmove event and maps refuses to click.

In addition, Fennec actually supports some of the Level 2 draft for touch events, which includes things like force and radius (NOTE: This spec is still in development and is likely to change, so use those with caution). So if a user presses on a single spot on the screen and then continues pressing harder and harder, we fire touchmove events for all those force/radius changes even though the users finger is still at (approximately) the same place.

All of that means the above code doesn’t actually work for us unless we filter out at least this very first touchmove event and don’t fire it until the user has actually moved their finger a significant distance on the screen. For now, that’s what we’ve done to make maps work for our users.

The correct code should check for some minimum distance after the initial touchstart event. If you get a touchmove that’s further away than that, you’re dragging! Ideally you’d have access to the device dpi here and you could use units of mm or something, but I can’t find a webapi for device dpi (yet?). This post is already getting too long, so I’ll leave that as an exercise to the reader.

“tap” events with some sort of number indicating how many taps have occurred in approximately the same place would probably be a useful addition to the touch events spec. (I noticed the other day that we actually have an internal MozGestureTap event that isn’t implemented in Fennec and isn’t exposed to web content (yet)). For now the EASIEST way to get around some of these problems is to use something like zepto, jquerymobile, or pointer.js which abstract this and other useful “gestures” for you.

1. History (cache,history,downloads,formdata)
2. Passwords (cookies,passwords,sessions,syncAccount)
3. Site Preferences (offlineApps,geolocation,siteSettings)

and only clear them for certain time frames (One hour, Two hours, Four hours, a Day, and Forever). Porting it gives a chance to show off some new things we can do. Turned out, porting it was really easy though. In fact, a lot of the code it was using in XUL Fennec isn’t even necessary anymore thanks to some additions to the platform! Quick overview:

Step One: Updating compatibility

This steps pretty easy. We just need to mark Cleary as compatible on our install.rdf

<em:targetApplication>
  <Description>
    <em:id>{aa3c5121-dab2-40e2-81ca-7ea25febc110}</em:id>
    <em:minVersion>14.0b1</em:minVersion>
    <em:maxVersion>15.0</em:maxVersion>
  </Description>
</em:targetApplication>

Updating our UI

Cleary (luckily), is a bootstrapped extension and doesn’t include any overlays. While you could potentially use an overlay in Native Fennec, I’d highly discourage addon authors from doing it.

So to update our UI here basically means altering some scripts so that they only run on XUL Fennec. I decided an easy way to do that here was just to check the app id:

if (Services.appInfo.ID == "{a23983c0-fd0e-11dc-95ff-0800200c9a66}") {
  // setup xul fennec
} else {
  // do nothing!
}

Inside here the XUL Fennec code creates some buttons and rows for the Preferences pane. Overlaying things into prefs isn’t possible in Native yet, so we can basically do nothing! In some cases you might opt to use our NativeWindow interface to add UI elements. Instead, I’m opting to include some inline options for the addon.

settings.xul also happened to already be in Cleary. I just used some trickery to display it in the normal settings list. It also included some things we didn’t want, like a <settings> element, which I’m pretty sure Native Fennec will not like, so I removed that and just created a new options.xul in the root of the addon.

We also need to re hook up our click listeners to the clear buttons in the dialog. This requires a fix for Fennec that hopefully we can push into the beta. In bootstrap.js we need to add a listener for “addon-options-displayed” notifications:

Services.obs.addObserver(observer, "addon-options-displayed", false)

and a little observer to see them trigger:

var observer = {
  observe: function(aSubject, aTopic, aData) {
    if (aTopic == "addon-options-displayed" && aData == "cleary@digdug.org") {
      var doc = aSubject;
      var control = doc.getElementsByClassName("clearButton");
      for (var i = 0; i < control.length; i++) {
        var c = doc.defaultView.gChromeWin.cleary;
        control[i].addEventListener("command", c.doClear.bind(c), false);
      }
    }
  }
};

The old settings.xul was also localized using some JS trickery, which won’t work now. BUT!!! bootstrapped addons now support a chrome.manifest file, so we can add it and save ourselves some work. At the same time, I can remove a bunch of junk I had to register a resource URL and load style sheets. Yay for simplifying! We just add a chrome.manifest file with:

content cleary content/
locale cleary en-US locales/
style chrome://browser/content/browser.xul chrome://cleary/content/dialog.css

Functionality

Most of the functionality we previously had will just work in Native Fennec. Passwords, Form history, Cache, Cookies, Downloads, etc. All of its the same (and the same as desktop).

Except! browsing history is no longer handled in Gecko at all. Its all done in Java. Eventually Fennec should expose an interface for this, ideally that one that mirrors nsIBrowserHistory. I filed bug 731888 awhile ago for a slightly less hacky fix as well, but need to put up a correct patch there (volunteers welcome!).

For now, I had to hack into the database. This is NOT recommended. It will probably break eventually, and it will definitely make kittens cry but you can open the history database using the mozStorage service and tinker around in it. That may crash some phones where Android’s sqlite assuredly won’t match Gecko’s, so be warned! For history I added:

let file = FileUtils.getFile("ProfD", ["browser.db"]);
let dbConn = Services.storage.openDatabase(file);
if (this.range) {
  var statement = dbConn.createStatement("DELETE FROM history WHERE :from_date <= date AND date <= :to_date "
  statement.params.from_date = this.range[0];
  statement.params.to_date = this.range[1];
  statement.executeAsync();
} else {
  dbConn.executeSimpleSQL("DELETE FROM history");
}

And we’re done! There’s a build with this on Dropbox here, but it will not work until bug 756689 is fixed an checked in (and be warned its not on AMO because I’m still testing! Dataloss definitely possible!) There’s some bugs here I need to look into (clicks in the options dialog seem to fire multiple times and there’s some oddity with menulists), and I haven’t tested on XUL Fennec yet. For things that delete your data, there’s always lots and lots and LOTS of testing to do. But for the most part the port was pretty easy.

I’m pumped about Native Fennec. Its a great browser, and having extensions work in it is just icing on the cake. I’m excited to see what some good add-on developers can come up with to do with it in order to fix and enhance the mobile web.

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.