Mark Finkle’s Weblog

In previous versions of Firefox Mobile, you could check for and install updates for your add-ons by pressing the “Update” button in the Add-ons Manager. This meant that you could check whenever and as often as you wanted, but, if you didn’t really want to manage these things manually, you could find yourself without the latest versions.

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.

With Firefox 1.1 Beta 1 for Maemo ready to go and the final release not far away, now is an excellent time for add-on developers to update their add-ons. Obviously, Mozilla wants as many add-ons as possible to be compatible with the latest version of Firefox Mobile.

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.

Fennec 1.1 now supports context menus. Using a long tap (aka tap-n-hold), or right-click on desktop versions, you can get a context menu to appear.

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.

There has been a lot of discussion about the future of the Mozilla add-on infrastructure. I think it’s clear now that Mozilla is not removing the classic add-on mechanism. In fact, Fabrice Desré found a nice bit of news on an upcoming feature (via comments on Atul’s post):

Fabrice: Does the fact that jetpacks are now XPIs mean that the “no restart after install” feature will be implemented for traditionnal add-ons ?

Atul: That’s correct! We don’t have a bug filed for it yet, still need to do that, but the idea is that if an extension includes certain metadata in its install.rdf that essentially tells Firefox “look, I know how to unload all my resources reliably”, then Firefox will trust it and call a certain function whenever the extension needs to unload itself.

Mossop: I’ll just elaborate a little. Plans are naturally in flux right now but the idea is to allow XPI packages to install without restarts if they wish, however there will be constraints. They will be responsible for doing everything themselves, which means (at least in my head right now) we won’t automatically load chrome or components from these extensions. Instead we will just do startup and shutdown calls into the extension and allow it to register/unregister what it needs by itself. This means that just marking an existing extension to work without restarts wouldn’t get you anywhere, you still need to do the extra work to handle the startup/shutdown parts.

This is great news for add-on developers! I’m sure MDC will have some code snippets for dynamically loading chrome overlays and components to make it easy to support no-restart add-ons.

Thanks to Fabrice Desré and Wladimir Palant, development builds of AdBlock Plus support Fennec! The port embraces Fennec’s minimalistic design asthetic – exposing only a simple options UI. However, this is more than enough to make a great impact on browsing in Fennec.

Besides reducing the visual clutter on web pages, ad-heavy pages load noticeably faster! As Wladimir notes in his post, AdBlock Plus will only work in nightly builds of Fennec (version 1.0b6pre). Install a nightly version (including desktop versions) or use the new nightly update channel from your Maemo device. He also mentions that work to improve the first-run experience is coming in future releases.

Install a development build of AdBlock Plus by navigating to https://adblockplus.org/devbuilds/adblockplus/ using Fennec and click on the most recent XPI file. Fennec will step you through installing the add-on.

We’re in the last weeks of development before releasing Fennec 1.0 to the world. There has been a lot of great testing and feedback. I think we have a well defined set of things to work on for 1.0 and a good idea of what we want to look at for 1.0+.

However, there is one area I think we haven’t had enough testing and feedback – add-on development in Fennec. Add-on developers are a tricky bunch. They can make you re-think your architecture, brainstorm many new features and find lot’s of hidden bugs. We need more developers working on Fennec add-ons.

We have a small, but growing collection of Fennec-specific add-on developer resources. If you’re interested in building add-ons for Fennec, here’s a list of resources you might find helpful:

• Architecture Overview
• Extensions Basics – Look here first
• Code Snippets – Doing things in Fennec might be different than Firefox
• Best Practices for Building Extensions
• Creating an Options UI for an Extension
• Tips for Creating a Robust UI – XUL and CSS to the rescue

The documents have been, and will continue to be updated. Feel free to give feedback on any of the documents. What information or snippets are missing? Use comments, IRC channels (#mobile) or even file some bugs.

Fennec for Maemo and Fennec for Windows Mobile both support add-ons. In fact, the same add-on could be used on both platforms. So get out there are start building.

Oh, one thing I wanted to ask before you go. What features of a mobile device would make building mobile add-ons really kick ass? Support for geo-location? Accessing the camera? Making calls or sending SMS? Leave comments and please go into detail

The add-on (extension) mechanism built into the Mozilla platform is very powerful. One of the optional features is support for options (preferences) dialogs. As discussed in my last post, Fennec doesn’t like dialogs. In addition, Fennec has a simple, clean preference system. While designing the Fennec Add-ons Manager, we discussed how we would support add-on options. We didn’t want popup dialogs of random and complicated XUL.

After brainstorming a few ideas, we settled on a simple idea. Fennec uses special <setting> XUL tags to create it’s list of preferences. Add-ons would be forced to use the same tags. The options would be merged into the Fennec Add-on Manager, not displayed as a popup dialog. Of course, add-ons can support more than one application, so we needed to make sure that the options XUL for Fennec could coexist with the options XUL for other applications. Let’s take a look at how this all works:

Install Manifest

Add-ons use install.rdf to identify the XUL used for displaying the preferences. This is optional.

<em:optionsURL>chrome://myaddon/content/options.xul</em:optionsURL>

This is needed for any add-on that wants to use an options dialog.

Chrome Manifest

Add-ons use the chrome manifest to selectively override XUL, and other resources, between different applications using the application flags

override chrome://myaddon/content/options.xul chrome://myaddon/content/fennec-options.xul application={a23983c0-fd0e-11dc-95ff-0800200c9a66}

This will tell Mozilla to use fennec-options.xul anytime the options.xul resource is requested.

Options XUL

As I said, the XUL allowed for the Fennec options system is limited to a few new tags. Here is an example of a Fennec options dialog:

<?xml version="1.0"?>

<!DOCTYPE mydialog SYSTEM "chrome://myextension/locale/mydialog.dtd">

<vbox xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
  <setting pref="extensions.myaddon.debugging" type="boolint" on="1" off="2" title="Enable debugging"/>
  <setting pref="extensions.myaddon.profiling" type="bool" title="Enable profiling">
    Profiling can affect the performance of the application
  </setting>
  <setting pref="extensions.myaddon.logging" type="bool" title="Save logs"/>
  <setting pref="extensions.myaddon.logging.path" type="string" title="Log folder"/>
  <setting type="button" title="Clear logs">
    <button label="Clear" oncommand="MyAddon.clearLogs();"/>
  </setting>
</vbox>

Note that we don’t have any <script> support and we are limited to <setting> tags. The root <vbox> just acts as a container, it isn’t merged into the main window. Here is how the options look in Fennec:

As always, we appreciate your feedback. I’m in the process of updating the Fennec Best Practices documents with this information.

A big thank you goes out to Vivien Nicolas, a Mozilla intern in the Paris office, for turning my super-great design into a reality. Shaver told me there’d be days like this!

If you’ve developed applications or extensions using the Mozilla platform, you know that there are tons of services and APIs available. We use those same capabilities when building Fennec. However, there are times when the default platform behavior is not desirable on mobile devices. When that happens, we could hack up our own system, or we could re-implement the platform APIs to suit our needs. We try to do the latter.

Here are some APIs that have been reimplemented in Fennec: nsIAlertsService, nsIPromptService, nsIDownloadManagerUI, and window.openDialog(). The primary reason all of these APIs have been reimplemented is that they open new XUL windows. We don’t like doing that in Fennec. Mostly because opening a XUL window is slow. But also because we love having tighter control over the look, feel and behavior of the UI elements.

Services

Since we re-implement the interfaces, nsIAlertsService, nsIPromptService and nsIDownloadManagerUI can be used just as they are on the desktop. The big difference is that none of them open new windows. The UI is embedded into the main window itself. It’s faster to display and easier to control and style the UI elements. In the case of the download manager, it’s designed to be embedded in the main window.

Dialogs

On the other hand, we couldn’t exactly match the way window.openDialog() worked, so we created a slightly different API: importDialog(). The big difference is that importDialog() actually merges the XUL dialog into the main window. It does not open a new XUL window.

importDialog(aSrc, aArguments);

• aSrc: The chrome URL of the XUL dialog
• aArguments: A JavaScript object used to pass data to the dialog

The XUL passed to importDialog() is very similar to XUL passed to window.openDialog(), with some limitations and caveats:

• Only <dialog> top level elements are permitted
• Scripts are loaded via an attribute on the <dialog> element, not via the <script> tag

Here is an example:

<?xml version="1.0"?>
<!DOCTYPE mydialog SYSTEM "chrome://myextension/locale/mydialog.dtd">
<dialog xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
      script="chrome://myextension/content/mydialog.js">
  
  <label id="mydialog-title" crop="center"/>

... some other widgets ...

  <hbox pack="center">
    <button label="&ok.label;" oncommand="myDialog.doSomething();"/>
  </hbox>
</dialog>

The XUL is merged into the existing window, almost like a XUL overlay. Because of this, element ID and JavaScript conflicts are possible, just like overlays. So be careful!

Obviously, add-on developers should use these features. We are looking for feedback as well. Perhaps we could get importDialog() working more like window.openDialog().

A big thank you goes out to Fabrice Desré for working on reimplementing nsIPromptService. He created some great building blocks for Fennec.

Designing a portable application to run on many different mobile devices is a challenge. Screen sizes and pixel densities are different making it difficult to create the One Great Layout. In addition, mobile devices can change screen orientation, from portrait to landscape and back again.

This is one area where using a markup-based UI language like XUL, with it’s support for CSS, comes in handy. Currently, Fennec is being designed and tested to run on Nokia’s N810 & N900 devices, HTC’s Touch Pro and Samsung’s Omnia & Omnia II. Yes, Fennec can run on other Windows Mobile devices, but we don’t really test on every possible device… yet. Joel and the QA crew are working on that, but I digress.

Even with the target devices, we have several screen sizes, pixel densities and orientation requirements to support. Layout support in XUL and media query support in CSS really do the heavy lifting for us. The Fennec UI is the same on all these devices, but we have some layout constraints and CSS rules that allow us to morph the UI as the screen changes. Here are some of the ways we do it:

• Use physical dimensions whenever possible. Padding and margins are set using millimeters, not pixels. This minimizes the need for special rules for every different screen size and pixel density. Also, the UI is designed for touch, and the current design size for a touchable UI element is ~7.5mm. Your finger doesn’t change sizes to match the screen
• Use CSS media queries to switch between screen sizes and pixel densities. Large sized images can be used on large screens/densities, while smaller images can be used on smaller screens/densities. The result should be an image that is roughly the same physical size on either device.
• Use CSS media queries and XUL box rules to flow the UI when the device is rotated. A toolbar that works well vertically in landscape orientation, probably needs to flow horizontally in portrait orientation. It’s all about maximizing the usable space.

Screen Size

Here is some example CSS we use for toggling between large and small screens/densities. As you can see, we use 400px as a cutoff:

/* high-res screens */
@media all and (min-device-width: 401px) {
  toolbarbutton {
    min-width: 64px !important; /* primary button size (match image pixels)*/
    min-height: 64px !important; /* primary button size (match image pixels) */
  }
}

/* low-res screens */
@media all and (max-device-width: 400px) {
  toolbarbutton {
    min-width: 36px !important; /* primary button size (match image pixels) */
    min-height: 36px !important; /* primary button size (match image pixels) */
  }
}

Orientation

The same kind of example, but this time for changing the direction of some UI elements when rotating the screen:

@media (orientation: landscape) {
  #panel-controls {
    -moz-box-orient: vertical;
    -moz-box-ordinal-group: 1; /* move to left of screen */
    -moz-box-pack: end; /* force children to align to bottom of screen */
  }
}

@media (orientation: portrait) {
  #panel-controls {
    -moz-box-orient: horizontal;
    -moz-box-ordinal-group: 1000; /* move to the bottom of the screen */
    -moz-box-pack: start; /* force children to align to left of screen */
  }
}

We also use the XUL box wrapping tip, I discussed previously, to allow elements to flow into multiple rows if there is not enough space to hold them in a single row.

If you’re developing add-ons for Fennec, please keep these situations in mind. Use the Fennec code as an example of how you can create a great user experience, regardless of screen size or orientation.

So much to do, so little time. My workspace is littered with projects I started but couldn’t find the time to keep going. It’s kinda sad and I do feel guilty.

Sometimes those projects find a new life. Recently, two of my old projects found new life: FizzyPop and js-ctypes are both active again.

Doug Warner has started building a Mozilla Project Wizard on the FizzyPop source code. Doug is requesting feedback for improvements. You can try it out here.

Dan Witte has started looking into moving js-ctypes into the Mozilla tree! There are also plans to add a nice JavaScript wrapper API around the XPCOM too.

I feel less guilty now.