User:RPL/drafts/JEP xyz Chrome Support

From MozillaWiki
Jump to: navigation, search

JEP XYZ - Chrome Support

TODO

  • better describe addons scenario
  • add some detail on how to reach jetpack-sdk modules from chrome and chrome from jetpack-sdk
  • file a ticket for default prefs patch
  • file a ticket on optional arbitrary jetpack id
  • prototype package.json attribute 'cfx-flags'
  • prototype 'cfx xpi' option --standalone
  • check how to mark 'require reboot' an extension's install.rdf

Proposal

Allow jetpack-sdk to support development of full standalone XULRunner applications and help transition of existent Mozilla Application's addons from the "old chrome.manifest and XUL overlays"-based style to the "new jetpack commonjs modules/packages"-based one

Requirements & Key Issues

  • cfx xpi should optionally allow arbitrary id (and bypass cryptographic generation and check introduced by JEP 118 - 'JetpackID')
  • cfx run and cfx xpi should check presence of chrome.manifest and chrome dirs
  • cfx run/xpi should mark generated extensions to 'require reboot'
  • cfx run/xpi should copy default_prefs.js into defaults/prefs/jetpack_id.js
  • cfx xpi should generate and include an application.ini file and rename file to zip on --standalone option
  • add cfx-flags as package.json attribute to specify optional package flags ('forced_id', 'standalone', 'chrome_manifest')

Dependencies

  • bug 559306 - add support for chrome.manifest and chrome dirs for main jetpack package into cfx run and cfx xpi
  • bug 564023 - optional targetApplications attribute in package.json
  • bug 560781 - the SDK should support development of standalone xulrunner applications

Capabilities Required (if applicable)

  • full privileges
  • chrome.manifest loading

API Methods (if applicable)

This JEP don't need or expose further APIs over the existent ones.

Use Cases

Use Case 1: full standalone XULRunner application

Bob needs to create a Hybrid Web/Desktop application and choose to use XULRunner as the core engine and jetpack-sdk as commonjs framework.

Bob creates a new jetpack-sdk package and asks jetpack-sdk to use 'forced_id', 'chrome_manifest' and 'standalone' cfx flags from the package.json: 

  {
    "id": "standaloneapp@alcacoop.it
    "name": "standaloneapp",
    "fullName": "My New Shiny Standalone App",
    "vendor": "alcacoop.it",
    "description": "Standalone Hybrid Web/Desktop App based on XULRunner and jetpack-sdk",
    "author": "Luca Greco (http://ubik.cc/) <luca.greco@alcacoop.it>",
    "version": "0.1",
    "license": "MPL 1.1/GPL 2.0/LGPL 2.1",
    "dependencies": ["jetpack-core"],
    "cfx-flags": [ "forced_id", "chrome_manifest", "standalone_app" ]
  }

Use Case 2: migration of old-style addons to jetpack-sdk

Bob develops a successfull and complex Firefox/Thunderbird/Fennec addon and he wants to port it to jetpack-sdk, but he can't rewrite all the addon's code in a single refactoring, and jetpack-sdk don't expose enough apis to cover the platform features Bob's addons already use.

So Bob choose to refactor core code of his addon into jetpack-sdk commonjs modules first, but continue to use old overlays and localizations chrome urls. 

  {
    "id": "myoldstyleextensionid@alcacoop.it
    "name": "myoldstyleextension",
    "fullName": "My Old Style Extension",
    "vendor": "alcacoop.it",
    "description": "My Old Style Extension (partially ported to jetpack sdk)",
    "author": "Luca Greco (http://ubik.cc/) <luca.greco@alcacoop.it>",
    "version": "0.1",
    "license": "MPL 1.1/GPL 2.0/LGPL 2.1",
    "dependencies": ["jetpack-core"],
    "cfx-flags": [ "forced_id", "chrome_manifest" ]
  }

After a couple of months a new jetpack-sdk release add some new module so Bob chooses to do a refactoring on the remaining parts of the addon to take advantage of the new jetpack-sdk features and to give his users a full jetpack-sdk based addon that don't need to force Firefox restarts after installing or updating.

Retrieved from "https://wiki.mozilla.org/index.php?title=User:RPL/drafts/JEP_xyz_Chrome_Support&oldid=227330"