Toolkit:Platform Specific Extension Components

From MozillaWiki
Jump to: navigation, search

Support for platform directories was checked in and is now documented at mdc:Bundles . --Jens.b 14:09, 8 Jun 2005 (PDT)

Introduction

Some extensions are only intended for one platform, either because it uses things other platforms don't have (e.g. the Windows registry, like Linky does), or because they have binary components. Both the extension manager and services like http://addons.mozilla.org/ would benefit if extensions had some sort of platform-compatibility information as part of their metadata. Note that themes are handled like extensions in some places, so they could include use such platform-compatibility information, too.

However, solving this issue is not enough, as two problems remain:

Problem 1

A growing number of Firefox and Thunderbird extensions use compiled, binary components. To keep the cross-platform nature Extensions usually have, you have to provide these binaries for each supported platform. Currently, all these are stuffed into the components/ directory. If you put binaries for several platforms into this components/ directory, you encounter the problem that Win32 loads not only .dll files, but also tries to load linux .so ones and fails with an error message.

The effect is that most extensions either

  1. are available in separate XPIs for each platform, posing problems for updating and http://addons.mozilla.org/
  2. include all platform binaries in one package and employ hacks to work around the problem

Needless to say, both alternatives aren't very appealing for extension authors.

Another problem is that binary components have to use the same ABI as the host application, or they won't work. Currently, there is no way to check or enforce this - when you install a linux-gcc2-built extension into a linux-gcc3-built application, things just break.

Problem 2

Some themes currently need a separate Macintosh version. While platform compatibility info as part of the metadata would make it impossible for a user to accidently install the wrong package, it would certainly be nice to be able to have one multi-platform theme package that includes some generic "base" files and some platform-specific ones.

Conclusions

We need...

  1. components that are only loaded if they were compiled for the same platform AND using the same ABI as the host application (Firefox, Thunderbird)
  2. platform-specific theme jar files, default preferences, window icons and whatever ("this fileset for windows, that one for mac")

The Solution

The notion of "platform file sets" is added by introducing a new subdirectory inside extension and theme packages: the platform directory. For each set of files that somehow depend on the target environment, it contains a directory named in one of the following ways:

  • [OS_TARGET]
  • [OS_TARGET]_[ABI]

OS_TARGET

The platform the host application was compiled for, e.g. WINNT, Linux, Darwin (meaning Mac OS X)...

ABI

The application binary interface the component was built with - e.g. gcc2, gcc3, mingw, msvc.

In each of these directories, the regular directory structure of the package (chrome, components, defaults for extensions, or the package dirs for themes) is repeated as needed.

The Extension Manager will install the package as usual - i.e. it extracts all files in the archive. The toolkit's nsXREDirProvider is enhanced so it automatically considers not only the extension's base directory, but also the matching platform directories.

A Firefox version built with MSVC for Windows would therefore try to load components and default preferences from directories listed below (if existing), and totally ignore any other subdirectories of platform/.

  • components/
  • defaults/preferences/
  • platform/WINNT/components/
  • platform/WINNT/defaults/preferences/
  • platform/WINNT_msvc/components/
  • platform/WINNT_msvc/defaults/preferences/

Older Firefox releases would also ignore everything in platform/.

Example Extension Structure

myExt.xpi:
   install.rdf
   chrome/:
      myExt.jar
   defaults/:
      preferences/:
         myExt.js
   platform/:
      Linux_gcc2/:
         components/:
            mycomponent.so
      Linux_gcc3/:
         components/:
            mycomponent.so
      WINNT/:
         defaults/:
            preferences/:
               myExt-win.js
      WINNT_msvc/:
         components/:
            mycomponent.dll
      WINNT_mingw/:
         components/:
            mycomponent.dll

Resolved Issues

What happens when we put chrome jar files in the platform directories - do they have to be listed in the main chrome.manifest? What if the current platform doesn't have that file, is it just ignored?
Each platform directory may have its own chrome.manifest: 
chrome.manifest
platform/WINNT/chrome.manifest
platform/WINNT_msvc/chrome.manifest

What happens to preference files - what happens if two have the same name, in which sequence are they loaded, are prefs overwritten if specified in both the base prefs file and a platform-specific one?

Yes, we should read the "base" preferences first, then the platform-specific ones, and the pref system will automatically override any duplicate prefs.

Bug References

Retrieved from "https://wiki.mozilla.org/index.php?title=Toolkit:Platform_Specific_Extension_Components&oldid=290138"