Please follow up (add comments) to the newsgroup post.

The Mobile team integrated the basic user interface for Firefox Sync directly into Fennec. Now you can synchronize your tabs, history, bookmarks, form data and passwords – desktop to mobile device and back again – without installing an add-on!

If you’re using a nightly Fennec 2.0a1pre build, take a look in the preferences area for the Sync settings. We’re not finished yet. Plans for Fennec 2.0 include re-organizing the UI for accessing remote-synced tabs.

The biggest changes are related to out-of-process web content (Project Electrolysis) and accelerated rendering (Project Layers). Significant amounts of platform work have been done on both projects. Fennec 2.0 will integrate both Electrolysis and Layers.

Electrolysis will be the first of the two making an appearance in Fennec. Benjamin Smedberg’s kickoff post for Electrolysis summarizes the project goals:

• Increased stability: if a plugin or webpage tries to use all the processor, memory, or even crashes, a process can isolate that bad behavior from the rest of the browser.
• Performance: By splitting work up among multiple processes, the browser can make use of multiple processor cores available on modern desktop computers and the next generation of mobile processors. The user interface can also be more responsive because it doesn’t need to block on long-running web page activities.
• Security: If the operating system can run a process with lower privileges, the browser can isolate web pages from the rest of the computer, making it harder for attackers to infect a computer.

In fact, Electrolysis has already been used in Firefox 3.6.4 to protect against plugin crashes. Fennec will extend this beyond plugins to the entire web content. All web content will execute in a separate process from the main application. This does create some interesting code changes for both the application and add-ons.

We started a transition document and I’ll cover more details on those changes soon. Look for multi-process web content to appear in Fennec 2.0 Alpha 1 – coming soon.

Work to integrate Layers into Fennec will start shortly after the release of Alpha 1. In addition to the potential of hardware accelerated rendering on mobile devices, Layers also allows Fennec to remove the custom built canvas-tile-cache rendering solution used to achieve decent panning performance and responsiveness. Layers supports a “retained mode” rendering system, which means the application can drop the canvas-tile-cache system and use traditional XUL <browser> elements for the browsing surface.

There is a lot of work to do, but progress is happening at a surprisingly fast pace. Fennec 1.1 adds a lot of solid UX features and although we’ll continue to improve the UX for Fennec 2.0, the primary reasons for many of the platform changes are: Speed, Responsiveness and Stability!

Firefox for Maemo 1.1 RC 1 is ready to install. For this release, the focus was some UI features we didn’t have time to put in the initial release. We also used your feedback from previous releases and nightly builds to help improve the browsing experience.

Some of the bigger features include:

• Form assistant improvements, including autocomplete
• Start Page redesign
• Auto update add-ons
• New smart-tapping system for better tapping links, fields and buttons
• Portrait support on N900
• Context Menu with Open Link in New Tab and Save Image
• Web content theme update
• Improved Site Menu
• Use volume keys to zoom on N900
• Save page to PDF
• Built in Crash Reporter

As always, we’ve provided unbranded Fennec desktop builds on Windows, Mac, and Linux. You can use these if you don’t have a Maemo device or to aid in add-on development. This is the final call for Add-on developers to update their add-ons from Firefox 1.0.x for Maemo.

Note to Ovi Store Customers: If you installed Firefox 1.0.x from the Ovi Store, you will not be able to upgrade to Firefox 1.1 RC 1 (either from the N900 Application Manager or by downloading the software from Mozilla). We are working to solve this for future releases so that anyone can participate in our Beta programs. Don’t worry, though, if you got Firefox 1.0.x from either the Ovi store or directly from Mozilla, you will be updated to Firefox 1.1 (final) when it is released.

Desktop versions of Firefox will prompt you that a new version of an add-on is available. Maybe this prompt is enough for you to actually update the add-on, maybe it isn’t. Maybe you find the whole process annoying and/or boring.

In Firefox Mobile 1.1, we introduce automatic add-on upgrades. Once a day, Firefox will check your add-ons for an update and if an update is found, we download and install the new version. If you’re interested, you can go to the Add-ons Manager and see what add-ons have been updated. If you’re eager to use the new add-on, you can restart. In the future, some add-ons may not even need a restart.

Of course, you can still use the “Update” button to force add-ons to update right away, without waiting for the next automatic check.

If you want to turn off automatic add-on updates, you can use about:config and set extensions.autoupdate.enabled to false. If you’d like to change the timing for automatic updates, set extensions.autoupdate.interval to a different number of seconds.

Now, when Firefox Mobile (or Fennec nightlies) crash, you should see this application appear:

If you decide to send a crash report to Mozilla, and we really hope you do, you can see your crash, and other crashes, at the Mozilla Crash Reports web site. Here’s a list of all the Firefox Mobile crashes. For example:

You can also manage crash reports from Firefox Mobile itself. Use about:crashes to view all the crash reports created on your device:

Crash reporting and the data they provide will be a huge help to the mobile team. A big thank you goes out to everyone who helped get crash reporting enabled on Maemo!

It’s relatively easy to take these minimum sizes into account when designing your own interface. But what about when you’re displaying something that someone else has designed, and that wasn’t built with fingers in mind? This is the situation mobile browsers encounter in most web pages: links, fields, and buttons are often much smaller than you’d want them to be in order to tap on them, but making them bigger would interfere with the designer’s intended layout.

An approach that a number of touch-oriented OSes take is to make a small target’s tap-sensitive area larger, invisibly, than the visible target itself. This approach has been cleverly referred to as using “iceberg buttons” because the visible part of the target is much smaller than what’s lurking below. In fact, the iPhone does this with their keyboard as well, dynamically changing the invisible button target size based on what letters it predicts are most likely to come next.

Given how central link-tapping is to a browser, and how frustrating it is to tap the wrong link or not be able to tap at all, we decided to build our own approach.

Introducing SmartTap

In Firefox Mobile 1.1, we’ve added a smart-tapping scheme with the goal of allowing for accurate and easy tapping on links, form widgets and other focusable targets in web content. The main concepts of the approach are:

• Using a region, not just a point, to define the tap location
• Creating a list of focusable element candidates in the region of the tap
• Weight the elements by z-order
• Weight the elements by distance from the actual touch point
• Weight the links by number of visits

The result of the algorithm should be the element you were most likely trying to tap. Initial results show that tapping elements in Firefox Mobile 1.1 is much easy than previous versions. From a user’s perspective, taps just seem to work as they should.

Implementation Details

The code to support SmartTap was added to both the Mozilla platform and the Firefox front-end. It’s very flexible. The platform already exposes an elementFromPoint API to chrome and web content. The new API, nsIDOMWindowUtils.nodesFromRect, is very similar, but is only available to chrome content. For a given region, established by top/right/bottom/left, and a point, the method will return a list of possible DOM nodes.

The returned list is sorted in z-order. The Firefox front-end code then applies additional heuristics to the node list to find the most likely candidate. The code filters the nodes by “focusable” elements, weights by the distance of each node from touch point and, finally, weights visited links higher than other elements.

The region passed to nodesFromRect can be controlled via preferences (browser.ui.touch.top, browser.ui.touch.right, browser.ui.touch.bottom, browser.ui.touch.left). The weighting used for the visited links can also be adjusted using the browser.ui.touch.weight.visited preference.

Firefox Mobile uses a region that is offset more above the touch point. This has the affect of favoring elements above the touch point – which is based on our observations that people tend to “tap” below elements. Here’s a simple illustration:

click for larger image

The red dot is the actual touch point. The red box is the region passed to nodesFromRect. The title link will end up being “clicked” even though the author’s name text was actually “tapped.”

Another bit of intelligence in this system is based on the same insight that drives the Firefox awesomebar: that people tend to visit the same pages over and over again. Links are given higher weightings if they’ve been visited before, so visited links are more likely to “win” if a tap target is ambiguous because multiple small links are very close together. In practice, from the user’s perspective, tapping on the intended link just seems to work more often.

Thanks to Madhava Enros, Vivien Nicolas and Felipe Gomes for contributing to this post.

Firefox 1.1 Beta 1 for Maemo is ready to install. For this release, the focus was some UI features we didn’t have time to put in the initial release. We are also using your feedback from previous releases and nightly builds to help improve the browsing experience.

Some of the bigger features include:

• Form assistant improvements, including autocomplete
• Start Page redesign
• Auto update add-ons
• Portrait support on N900
• Context Menu with Open Link in New Tab and Save Image
• Web content theme update
• Manage site preferences (clearing passwords and others)
• Improved Site Menu
• Use volume keys to zoom on N900
• Save page to PDF

As always, we’ve provided unbranded Fennec desktop builds on Windows, Mac, and Linux. You can use these if you don’t have a Maemo device or to aid in add-on development. Add-on developers should use this release to update add-ons from Firefox 1.0.x for Maemo.

Note to Ovi Store Customers: If you installed Firefox 1.0 from the Ovi Store, you will not be able to upgrade to Firefox 1.1 Beta 1 (either from the N900 Application Manager or by downloading the software from Mozilla). We are working to solve this for future releases so that anyone can participate in our Beta programs. Don’t worry, though, if you got Firefox 1.0 from either the Ovi store or directly from Mozilla, you will be updated to Firefox 1.1 (final) when it is released.

We want to get as much feedback as possible before moving to a final release candidate, so please leave comments or file bugs.

AMO (addons.mozilla.org) is ready for add-ons to set maxVersion to 1.1.*

Please test your add-on before bumping the version. You can use the nightly builds for Maemo, as well as the desktop versions to help test. Here are a few things to keep in mind while testing add-ons:

• Site Menu: The site menu was redesigned and uses different XUL and JS. If your add-on adds a command to the site menu, please check out the changes and update your code.
• Context Menu: Long taps (or right clicks on desktop) will display a context menu, but only limited targets are allowed (images, links and mailto: links). If your add-on can benefit form the context menu, use it. But use it wisely.
• Startup: When starting the browser, the Awesomebar Screen is no longer shown. A true Start Page system is now used. Adjust your add-on startup process if needed.
• Portrait Mode: Firefox for Maemo (and Android) now supports dynamic portrait/landscape orientation. Make sure your add-on works well in both orientations.
• Theme Breakage: Check to make sure the add-on is not including the chrome://global/content/global.css stylesheet. It will break the mobile platform CSS. An easy way to see this breakage is to look at the toggle buttons in Preferences UI. If those buttons look like checkboxes, the CSS is broken. This seems to be very common for new add-ons.
• Check for Errors: When testing the add-on, launch the browser from a terminal and use | fennec –jsconsole | to open the JS Error Console. Make sure no errors appear in the console while testing the add-on.

If you have any questions, please use Mozilla IRC and join the #mobile channel. Use mibbit if you don’t have an IRC client. I’ll be there (mfinkle), as will many other helpful people who can help answer your questions.

We intentional designed the context menu system to be simple and minimalistic. We do not want large context menus with many, many commands. Currently, context menus are only displayed if the user long-taps on a link or an image. Technically, not all links will activate the context menu. javascript: links, for example will not activate the context menu.

Fennec 1.1 will only ship with two context menu commands: Open Link in New Tab and Save Image.

Add-ons can extend the context menu. Just overlay the context menu list of commands, which is <richlistbox id="context-commands"> in the XUL. Each command must have a type attribute and only 3 types are recognized: link, image, mailto.

The context menu system will automatically show/hide commands based on where the user long-taps. Under normal circumstances, the add-on will not need to worry about showing or hiding the context menu command:

• If an image is tapped, only type="image" commands will be shown.
• If the element is an image inside a link, both types of commands will be shown.
• If no link or image is picked, no context menu will be shown at all.

Yes, this is a bit restrictive, but that’s the way we want context menus to work for now. Feedback is always appreciated and Mozilla IRC (#mobile channel) is available to help answer questions.