Team LiB
Previous Section Next Section

Hack 91. Handle Cross-Platform Differences

Manage the differences among standard Firefox installs on different platforms.

Firefox works hard to provide the same user interface and web page displays on all platforms: Windows, Unix/Linux, and Macintosh. A great deal of effort has gone into this, especially with respect to the Gecko layout engine. Where the underlying operating systems are different, or where specific installations are different, differences can sometimes show through. This hack points out the most obvious cases and shows how to manage them.

At first, such differences might be irritating or awkward for users, but the consequences are felt mostly in XUL-based user-interface development, where a little care in constructing XUL documents is required.

Fundamentally, a single, compiled Firefox program cannot run on all platforms. Therefore, the standard Firefox install is created and customized separately for each platform. Although there is only one source code base, some small parts of it are operating-system-specific.

9.2.1. Handling Obvious Big-Ticket Differences

Human Interface Guidelines (HIGs) are standards that encourage all applications in a given desktop environment to provide similar idioms of use. Since HIGs for Apple, Microsoft, and Linux (e.g., GNOME) all differ, a tool that hopes to get a standards tick on every platform must look different on each platform. These are the big-ticket differences and how Firefox handles them:


The hidden window menu bar

The menu bar on the Macintosh is lifted to the desktop's system menu bar and doesn't appear on each window.

The Firefox Macintosh menu bar is automatically boosted to the system menu bar. This is the source of the hidden window feature sometimes remarked upon in Mozilla's Bugzilla. No action is required, unless your XUL application has no menu bar at all, in which case the system menu bar will be blank.


File and Print dialog boxes are different on each platform

Firefox wraps up the operating-system-supplied File and Print dialog boxes in XPCOM objects that present one interface on all platforms; use that. The XUL <dialog> tag contains buttons designed to support HIG dialogs on every platform, but in general, it must be carefully coded if it is to work portably and look right.


Accelerator keys sometimes differ

Macintosh has a Command key, Windows a Windows key, and Unix/Linux might make use of a Meta key. In general, keyboard shortcuts differ.

The XUL and XBL <key> tag accepts the generic term accel. This refers to the accelerator key native to the current platform: Alt on Windows, Command on Macintosh, and Alt or Meta on Unix/Linux. Firefox is also accompanied by a different set of keyboard shortcuts on each platform, with common keystrokes for most but not all popular commands. See the resource:/builtin/platformHTMLBindings.xml file for more details.


Different locations for user configuration system

The main user configuration system is under EditPreferences on Unix/Linux, under ToolsOptions on Windows, and under FirefoxPreferences on the Macintosh.

At the time of writing, there's no extension yet to make the menu location of the Options dialog box uniform across operating systems.


Unix/Linux Window managers tend to lack support for modal dialog boxes

Although it might be possible to make an application modal, it's usually not possible to force the focus to stay on the dialog window.

In addition to window.open(), secure web pages and chrome content can also call window.openDialog(). Both support the special keyword modal in their feature string argument; that keyword locks the parent window of the dialog box on all operating systems, so that it (at least) cannot get the focus back while the dialog box is open.


Command-line options differ

Differing command-line options is just part of life [Hack #10], unfortunately.


Desktop integration differs

Windows has a Windows Registry, Unix/Linux has a .gtkrc file, and desktop application icons (shortcuts/launchers) work differently.

The XPInstall system, which runs the install.js file bundled with the standard install and install.js scripts bundled with extensions, includes operating-system-specific features that such scripts can exploit. In particular it allows reading and writing to the Windows Registry, and knows the operating-system-specific locations of many important folders. Any secure script can exploit that information nonportably if it wishes. Examine these scripts for examples of nsIDirectory-style names at work.

Firefox obeys all window-management hints or instructions that it receives. Under X11/Gtk, a window cannot be 0 0 pixels in size (it can on Windows). There are no perfectly portable solutions for desktop theme integration [Hack #79], unfortunately, but with a lot of work you can come close.

9.2.2. Handling Widget Differences

Each operating system provides or supports a GUI library that can be used to draw interactive widgets. Firefox does not draw widgets using these libraries. Firefox uses its own widget-drawing code to draw widgets on a blank canvas supplied by those libraries. So, for example, Firefox for Windows does not depend on COMCTL32.DLL (or .OCX), and replacing that library is therefore of no use.

There are two areas of the desktop GUI that Firefox widgets depend upon. One is the theme engine for natively styled widgets [Hack #79] . Not all platforms support all -moz-appearance values, so applying such a style property can do nothing in some instances, but at least that's harmless.

The second area is the operating-system accessibility API. This is wrapped up in a portable XPCOM object with the nsIAccessible interface. It is used in the XBL definitions for XUL widgets [Hack #90] . You can't see the equivalent use for HTML tags unless you turn on XHTML tag support.

Where there is accessibility support, follow the guidelines at http://www.mozilla.org/access/xul-guidelines for best results in XUL.

In general, don't try to lay out XUL or HTML widgets in pixel-perfect style. What looks good on one operating system will be up for debate on another. It is better to pack widgets loosely, using the naturally flowing layout of the page: line boxes and blocks for HTML, boxes for XUL.

9.2.3. Handling Font Differences

Firefox must source, choose, analyze, resize and lay out font information [Hack #30] before it can ultimately be displayed. On Windows, Firefox uses some low-level features of GDI such as GetTextExtentPoint32 or ExtTextOutW, but ultimately it uses its own layout and font selection algorithms.

    Team LiB
    Previous Section Next Section