Porting Chrome Apps to Firefox OS Apps

 This article reviews the difference between Firefox OS appsChrome apps and provides examples for porting your Chrome app to an Open Web App.

Overall File Structure

Google Chrome apps are very similar to Firefox OS apps — they are built using web technologies, and their manifest file format is also similar to an extent, but the platforms differ in terms of syntax, file structures, and available APIs:

  • Open web apps will let you use any file structure you want — they are just web apps, so you can use accordingly.
  • Though, Chrome apps are pretty flexible in structure as well, but you need to know certain things . Chrome apps also have the concept of background pages, HTML/JavaScript that run in a background process and handle app functionality behind the scenes.

The manifest file

Both Chrome apps and Firefox OS Apps use a manifest file to define and control various parts of the app, including developer name and contact, icons to be used, and API permissions. Both use a JSON format and live in the root of the app directory. Let's move along and see what are the basic differences.

For our first example we'll use the Hello world  from the Google Chrome sample app repository. Grab this by running the following git command:

git clone https://github.com/GoogleChrome/chrome-app-samples

You can find a Firefox OS app version at David Clarke's github repository here:

git clone https://github.com/dclarke/firefox-os-sample-apps

Chrome manifest files have a .json extension. The original Hello world manifest.json looks like this:

 {  "manifest_version": 2,
    "name": "Hello World",
    "version": "2",
    "minimum_chrome_version": "23",
    "icons": {
         "16": "icon_16.png",
         "128": "icon_128.png"
     "app": {
         "background": {
         "scripts": ["main.js"]

Firefox OS App manifests have a .webapp extension; the converted manifest.webapp looks like so:

 {  "name": "Hello World",
    "description": "Hello World",
    "launch_path": "/index.html",
    "icons": {
        "128": "icon_128.png",
        "16": "icon_16.png"
    "developer": {
        "name": "David Clarke",
        "url": "https://github.com/onecyrenus/firefox-os-apps"
    "default_locale": "en",
    "permissions": {

TBD manifest features table showing the equivalents across the two formats (?????)

Reference docs:

API Support Differences

APIs support across Chrome apps and Firefox OS Apps differs; while porting an app , you will need to do an inventory of the platform-specific APIs you are using, write equivalent functionality for the target platform, and potentially create a level of abstraction around them. The naming & capabilities of the APIs vary across the platforms, and in this section we need to have a look  at the followings:

  • The different-but-equivalent device APIs supported across both platforms
  • Where to find more documentation on each platform
  • Which APIs have no commonality or equivalents across both platforms (Firefox or Chrome).

Note: Standard web APIs will work on both platforms.

WebAPI equivalents across platforms

The WebAPI equivalents that share common function across the two platforms are listed in the following table:

API equivalents across Chrome apps and Firefox OS web apps
API functionality Firefox OS/web app API Chrome app API
Alarms alarm Chrome alarms API
Audio getUserMedia (also handles video) audio API, also supports getUserMedia
Bluetooth Web Bluetooth (documentation coming very soon) bluetooth API
Device storage Device Storage API fileSystem API, mediaGalleries API
Persisting identity navigator.id API (used in Persona) identity API
Idle notification Idle API Chrome idle API
Location data Geolocation API location API (Chrome also supports the Geolocation API, but that is not compatible with event pages)
Notifications Web Notifications notifications API, events API
API Permissions Permissions API Chrome permissions API
Push notifications Simple Push API pushMessaging API (messages sent through Google cloud messaging)
TCP sockets TCP Socket API socket API (allows UDP connection)
Power management Power Management API power API
Context menus  contextmenus contextMenus

Read more information on some of the HTML5 APIs Chrome supports.

As a developer, you may wish to port apps between Chrome and Firefox OS. But the difficulty lies in converting functionality between equivalent but incompatible APIs, where the APIs used to deviate from web standard APIs. In most of the cases, the function calls are different as well as the data being returned. To work around this, you could manually code an abstraction layer, or use an intervening JavaScript framework like phonegap to abstract away such incompatibilities.

TBD: Show some examples of abstraction layer/ported apps?

Reference docs:

Chrome app API reference (chrome.*)

Mozilla Web API reference

Firefox OS APIs not supported in Chrome

There are a number of Open Web/Firefox OS APIs, which are not yet implemented in Chrome. These APIs are in their various stages of standardization, but they are all being considered and pushed forward for the W3C recommendation track.

Battery Status API
Provides information about the system's battery charge level and notify you as the battery level changes.
Provides access to the device's FM radio, allowing you to programmatically turn the radio on/off and switch between radio stations.
Vibration API
Provides access to the device's vibration hardware, which let software code provide physical feedback to the user by causing the device to shake.
Camera API
Allows applications to manage the device's camera, for example taking photographs, recording videos, and getting information about focus, zoom, white balance, flash, etc. It is a certified API so it can basically only be used by device vendor-supplied applications.
Proximity API
Allows applications to respond to proximity events, which are a handy way to know when a user is close to a device.
Time/Clock API
Allows applications to change  time/date of the system. It is a certified API so it can only be used by device vendor-supplied applications.
Ambient Light Sensor API
Allows applications to respond to any ambient light events, which are  handy way to make a web page or an application aware of any change in surrounding light intensity.
Device Orientation API
Allows applications to respond to changes in the device's physical orientation.
Screen Orientation API
Allows applications to detect and respond to changes in the orientation of the screen (i.e., portrait or landscape), including locking the orientation.
Web Activities
Defines a way for applications to delegate an activity to another (usually user-chosen) application, for example using the camera to take a picture, or using the dialer to initiate a phone call.

Chrome APIs not supported by Firefox OS

Chrome similarly has a set of APIs that are not supported by the Open web and therefore not implemented in Firefox OS. For now, lack of support in a platform just needs to be worked out in a different way.

app.window API
A concept  currently unavailable in Firefox: provides the ability to control window parameters, e.g., maximize, minimize, change window size.
app.runtime API
Another concept not currently available in Firefox: this is basically used to notify when the app has been restarted.
i18n API
An internationalization API that allows you to pull in and display different language strings for users in different locales.
serial API
Allows an application to read from  and write to a device connected to the serial port.
runtime API
API to retrieve the background page, return details about the manifest, and listen to and respond to events in the app or extension life cycle.
system.cpu, system.display, system.memory, and system.storage APIs
APIs to query system metadata.
tts API
Allows an application to play synthesized text-to-speech.
usb API
Allows an application to access and provide commands to connected USB devices.

Other differences


In summary

The takeaway from this article is to guide you accordingly, as you start writing your apps, and make sure you have a level of abstraction around APIs that are not standardized through the W3C. They may change, and your app will likely have to change as a result.

 With such a diverse new range of target devices appearing, it will be helpful for end devices to be able to read and write to serial and USB ports. This could enable a suite of new types of devices and functionality that we don’t really expect,otherwise. Think of Arduido, Raspberry Pi, etc.

Document Tags and Contributors

Last updated by: wbamberg,