To install this release, you can grab the cab from here. We’re also experimenting with an alternative exe installer, but only recommend it for users with unlocked devices due to the way Windows Mobile handles signing. It can be found here . For more detailed information on this release, check out the release notes.

Please try this release out and keep the feedback by coming filing bugs, commenting here or dropping in on the #mobile channel on irc.mozilla.org.

The new approach is to have a very light-weight daemon running on the device which a host machine can interact with to run commands.  Most likely the host machine will be running a python scripts very similar to those our current test machines do, with the exception of issuing the commands over an ip connection rather than locally.

Joel Maher went about modifying the existing test scripts (see bug 493748 and maemkit for an example) to issue their commands over ip for windows mobile and I took the task of writing the light-weight daemon, which I called test-agent (code can be found here).  Its a very basic telnet shell with a few built in commands.

Everything is pretty strait forward with the exception of the exec command which attaches a debugger process to the executed command to capture stdout, since Windows Mobile ostensibly doesn’t have stdout. If anyone knows of a better way to capture output from a process, I’m all ears.

Today this set-up ran through all 437 xpcshell tests for the first time on a Samsung Omnia II.  This is a major step forward and everyone is pretty excited (Yay team!).

Turns out you can tell Visual Studio to stop doing that.  Go to tool->options and expand the “Text editor” node and the “All Languages” node under that.  Then select tabs under that.  I set my indenting to “smart”, tab and indent size to 2 and (this is the key) enabled “Insert spaces”.  Its the “Insert Spaces” option that tells VS to use spaces instead of tabs.

The first thing you’ll notice is the improved start up time. Brian Crowder took Vladimir Vukicevic’s original dabblings for Firefox on Windows CE and produced a cross platform fast start daemon for Mozilla.  Stay tuned to his blog for a post I’m going going to nag him to write about it. One caveat is that this faster start up time doesn’t take effect until after you reboot your phone (hey, this is Windows after all).

The next thing you’ll probably notice is the much improved panning. We’ve implemented a tile cache rendering system (much like you see on google maps) that allows us to cache previously rendered content and avoid duplicating the work.  This has also allowed us to switch over to native scrolling surfaces which has greatly improved panning performance. Roy Frostig goes into much greater detail on this in his blog post on the tile cache.

Also helping out panning performance has been Robert O’Callahan’s compositor work, which reduces the amount of native widgets we have to deal with when rendering or scrolling and a change to keep track of the invalidated regions ourselves rather than rely on the system do it.

But wait, there’s more! If you’re running a phone other than the HTC Touch Pro, you’ll notice we now support a wider range of screen resolutions through the use of CSS media queries, which really show’s the power of our XUL based front end. And if you are running on the Touch Pro, go a head and run your finger around the edge of the directional pad.  That zooming you see is the result of Alexandru  Cristei’s work to support the touch sensitive directional pad on HTC’s Touch phones.

There is plenty more work to do (after all this is an Alpha release), but in writing this blog post I realize just how much progress we’ve made since Alpha 2. I hope you’ll give it a try, put it through its paces and enjoy. Oh, and file bug reports.

Update: There is now a shortened url for the cab installer bit.ly/wma3cab

There are lots of great front end changes for both platforms, which Stuart touched on with his post announcing the release. Mark posted more details about the new embedded error console. I’m really hoping he writes another post about some of the other front end improvements that made it into this release.

For Windows Mobile the most significant improvement in my mind is the great strides we made in painting and panning performance. This has been a true team effort. First we had some outside contributions of DirectDraw optimizations for cairo (bug 484864). Vlad worked to get them into the tree and finally Doug made the final push to get them working for Windows Mobile (bug 495298). Jeff Muizelaar can take credit as well for his work on pixman optimizations.

One caveat to these optimizations is that each Windows Mobile device has different hardware and different performance characteristics. We know that these optimizations will have no effect on several devices, even though they make a huge difference on the HTC Touch Pro and others. The

plan is to eventual switch the optimizations we use at runtime based on the hardware we are running on. The runtime switches have already landed (bug 488911), but the tests to determine the most effective optimizations for the hardware have yet to be written (bug 488547).

Since we started getting Fennec compiling on Windows Mobile a few months ago, we’ve made good progress:

• JeMalloc, the memory management library developed by Jason Evans and used by Firefox, has been ported to Windows CE and turned on for Fennec. This allows Fennec to manage memory much more efficiently.

• Fennec’s user interface controls have been rebuilt to be entirely CSS based. This will allow us to more easily adjust our UI for various screen sizes and resolutions in the future. Its also demonstrates how web technologies can be used to create compelling user interfaces. The look and feel will continue to evolve as we develop the product, but this release should give uses a sense of the direction its going in.

• Finally, this release also supports Add-ons. Add-ons are integral to promoting openness and innovation on the web and are unique to Fennec in the mobile space. Its been amazing to see how many great Add-ons have popped up already. Take for instance the gestures module created by Felipe .

As with previous releases, Madhava Enros has created a video walk through of this release.

Installation

This release has been targeted and tested on the HTC Touch Pro. We will be adding support for more devices in future releases. To install on your device, you can either navigate to this cab installer from your phone’s current browser or download it to your desktop and copy it to your device via ActiveSync. Once on your device simply click on the cab and it will install to your device. For more detailed installation instructions, look here and of course, please read the release notes.

Again, please note that some carriers filter web traffic to prevent their users from downloading cab files. If downloading the cab simply hangs or you get a message reading “This page contains erros and cannot be displayed,” this is probably what’s happening. In this case you will either need to be connected via WiFi or use the ActiveSync method.

The first time you run Fennec it will spend some time creating your profile. This may take a minute or two, please be patient.

Known Issues

It is not yet recommended to use this release for daily browsing tasks. Certain performance problems will become immediately apparent to the user. Panning has a noticeable delay between the user first touching the page and the page moving. We are certain that other less obvious bugs exist and we invite you to help bring them to light. You can find detailed information on how to file a good bug in bugzilla , our bug tracking system, here .

Looking Forward

Following the same path we took on Maemo, where the browser now performs quite well, development will now focus on performance improvements. There are known and suspected performance hot spots that need to be investigated and optimized. There are very talented people working on the core Mozilla platform who will continue to speed up things like JavaScript, graphics and the DOM. We are excited about a set of optimizations for drawing that take advantage of graphics processors, which will help Fennec’s graphics performance (i.e. panning and zooming). We are also looking at enhancements to our networking layer to optimize for high latency networks.

Now that we have gotten to this point, the fun really begins. If you would like to help us by testing or developing the product, please visit the Mobile Firefox wiki . There you will find some information that we hope is useful in helping you find where to “plug in” to the effort. As always, you can find us on irc in the #mobile channel .

It all comes down to memory.

Simply put, we were running out of memory. The frustrating part though, was that we weren’t running out of real memory. We were being constrained by an artificial limit of 32Mb (including the binary) that Windows CE places on each process. That is why otherwise extremely capable phones like the HTC Touch Pro with 288Mb of RAM were showing a beautiful checkerboard pattern. I’m still not entirely sure why this didn’t show up on our development devices before the release. I suspect it has something to do with the fact that we’re using unlocked HTC Touch Pros for development, while most of the testers seeing the problem were using handsets from Sprint, Verzion or AT&T.

Digging further, the reason people saw a checkerboard pattern, but otherwise usable UI is due in part to the way Fennec works. In Fennec, the user actually interacts with an html canvas element. We render the page off screen and then paint the image onto the canvas. In this particular case, it seems as though we were successfully rendering pages but failing to allocate enough memory to do the final paint onto Fennec’s canvas. We were handling this low memory “gracefully” and continuing to run.

jemalloc to the rescue

At first Doug Turner took a crack at cooling down this memory hot spot by improving on how we allocate memory during paints. Essentially, allocating a single buffer and reusing it every time he needed a surface to write to. This didn’t actually decrease the amount of memory we were using, but instead significantly reduced the amount of memory “thrashing,” (repeatedly allocating and freeing chunks of memory).

With that change we were able to run for much longer without running into memory problems, but it became clear that there are plenty of other places in our code that we thrash.

The solution was to use jemalloc, originally written by Jason Evans. Stuart and Vlad used jemalloc to greatly improve the memory performance of Firefox over a year ago, so it was already in the Mozilla bag of tricks.

Success!

Fearful of counting my chicks before they were hatched, I didn’t want to blog about this until it landed, and tonight it did. With jemalloc enabled on our windows ce build of Fennec I am able to start up without any worries of seeing a checkerboard.

…and I can browse to the two most memory intensive websites that I encounter on a regular basis (both of these have crashed my iPhone on occasion), the first being Planet Mozilla

…and the second being the Firefox tinderbox waterfall

I can even look at both at the same time!

With these bugs closed, we’re down to 5 blockers for our next release on Windows Mobile. Stay tuned.

Several use cases have been thrown around, but the one that rings the loudest for me goes something like this: You’re looking for a new restaurant to try from your laptop at home, find one and head out. Once you get to the neighborhood, you realize you have no idea where this hole in the wall place is. With tab syncing you can pull out your mobile device, launch Fennec and see a list of tabs open on your laptop (and all your other computers). You select the tab you need, and instantly are looking at the same content you had on your laptop.

Go checkout his write up, which includes screenshots of it working, at his blog. Great work Jono!

*Image taken directly from Jono’s blog

This release is pre-alpha, and intended to get the product into the hands of early adopters in order to get feed back and bug reports. In order to focus our efforts on getting this release out, we have targeted only one device, the HTC Touch Pro. This has a number of user interface implications, including graphics designed for a 300 dpi screen, control layout intended for a vga screen and reliance on a hardware keyboard for text input.

Installation

You can install this on your HTC Touch Pro by navigating to the cab installer with your existing browser. This will download the cab file and kick off the installation process.

Alternatively you can download the cab file to your desktop and transfer it to your device via activesync. Once the cab file has been copied to you device, navigate to it using file explorer (on the device) and click on the cab file to launch the installer.

Please note, its been brought to our attention that some carriers are filtering web traffic to preclude downloading cab files. If this is the case with your carrier, you’ll either have to download to your desktop and transfer by activesync, or be connected by wifi if you download directly to the device.

Status

Our focus to this point has been to have a working, usable browser. To get there in a hurry we have punted in a few places, and I’d like to point a couple of them out. First is the update mechanism (both for the browser itself and for extensions). After installing this release, you will not be offered updates automatically, so please stay tuned for follow up releases. Also, we have disabled plug-in support. This is one of our high priority items going forward. Finally, as I mentioned before, there is no soft keyboard support. On an HTC Touch Pro, you’ll have to slide out the keyboard to enter a url.

Besides the release, we marked another major milestone yesterday when the final patch to NSPR landed and we were able to build for Windows Mobile off Mozilla’s trunk for the first time ever. I say the first time because minimo was built from branches of both NSS and NSPR.

“leaks”

Over the last week and half there have been several blog posts and “news” articles floating around the internet about leaked Windows Mobile Fennec builds. This has been fairly entertaining to those of us working on the project for a couple reasons. First, the builds that these posts have pointed to are the builds that I pointed to on twitter. They were intended to be used by the developers working on the project (or anyone else willing to deal with really buggy software) to find bugs before we pushed anything out to the general public.

Also, the concept of secret, leaked builds flies in the face of how Mozilla operates. Our source code is out there for everyone to see. We have a bug reporting system that anyone can (and is encouraged to) access to file new bugs or track the progress of existing bugs. The majority of our discussion around the project is entirely public on irc, our wiki or our meetings and conference calls.

I have been working for Mozilla for 16 months now. At first its a bit of an adjustment to having everything you do or say out there in the public. But after overcoming that initial shock, its a point of pride. This project goes to extraordinary lengths to be open and transparent. If you are going to write about Mozilla, take advantage of that. Read our meeting minutes, hop on irc to ask a question or even dial into the weekly status meeting. Its all out there, just look.