Firefox/Projects/Jetpack Uplift Exploration/Notes

From MozillaWiki
Jump to: navigation, search
Draft-template-image.png THIS PAGE IS A WORKING DRAFT Pencil-emoji U270F-gray.png
The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly.
If you have any questions or ideas, please add them as a new topic on the discussion page.

Note: This assumes many things!

Uplift Scope

This describes a potential ideal scope, if Jetpack were to be shipped as part of Firefox.


  • Runtime

Not Included

  • Development environment (separate addon)
    • Code editor
    • Setting of development specific prefs (eg, javascript.options.showInConsole)
    • Firebug specific code
    • JSBridge
  • Development documentation (to be put on MDC)
  • Subscription UI (managed via new Extension Manager)
  • Workarounds for older version of Firefox
  • Personas specific code
  • First run experience

Uplifted separately

  • Slidebar (replace/improve current sidebar functionality)
  • JS security code (eg, securable membrane)

Subscription / Installation / Management

Platform requirements

Browser UI

Areas where Firefox should provide simple APIs:

Further in the Future

Extension Manager

Javascript / Sandboxing

  • JavaScript memory tracker
  • Object.freeze()
    • bug 492844 - ES5: Implement Object.freeze, Object.isFrozen
  • ChromeObjectWrapper (landed on trunk)


  • Transparent iframes
    • bug 235877 - Iframe elements in XUL (like 'page' etc.) can not be made transparent
    • bug 130078 - integrate iframe into chrome view hierarchy (link view managers / trees between chrome and content)
  • Lightweight iframes? Need some efficient way of sandboxing and displaying untrusted markup/code.
  • Scriptable HTML parser (;1 only handles XML)

Utility Libraries

Note: Not specific to Jetpack.

Provide utility libraries similar to FUEL but for non-browser stuff. For browser-related functions, FUEL can be expanded.


  • OAuth
  • Logging
  • More convenience wrappers around commonly used XPCOM components.

Native support for Content Scripts

Content scripts are JS scripts that run in content, but are provided by the browser, rather than by the website. This could be a potential first step in providing developers with native open-web tools to extend the browser. Currently this is provided by addons (Greasemonkey, and Jetpack has it planned). A technical exploration was done to see how Firefox could support this natively.


  • First-class support for content scripts
  • Must be secure - content space only, no chrome privileges

Technical exploration

  • Success
    • But needs support from new Extension Manager
  • Would work as both a standalone feature, and a platform for Jetpack (and other addons)


  • Technically sound, but need more discussion with Jetpack team

Jetpack requirements

  • Complete security model
    • Stabilize code
    • Test for vulnerabilities
  • Unit test coverage
  • Inclusion of metadata in Jetpacks
    • Author
    • License
    • Homepage
  • Remove use of jQuery in core (chrome) code
  • Code style review
  • Rework usage of iframes in statusbar
    • Most Jetpacks don't need full iframe functionality, which is expensive for how its used
    • Add API to add an image/button, with relevant event callbacks

Related Sprints

New Extension Manager API and UI

Windows Theme Revamp

  • This includes the possible/probable removal of the menubar and statusbar. These are the 2 most common areas for addons to extend. Even without these being removed, its clear that the browser window needs to provide more easy ways for things to be added to the UI, in areas that make sense.

Doorhanger notifications

Goal buckets

  • APIs: Existing and new capabilities that we believe need to be either abstracted from XPCOM (e.g. crypto) and XUL (e.g. menus), or created wholesale (e.g. slidebar), in order to enable at least 80% of the capabilities of popular add-ons
  • Platform and front-end changes required to enable these APIs as well as the nascent security model (re: work being done by mrbkap, lucas and atul on flexible membranes, securable modules, etc.)
  • Discovery, installation & asset management capabilities and interaction model required to support Jetpacks as first-class add-ons in the product



  • Would uplift include renaming?
    • Jetpack is a good code name, but maybe not a good feature name
    • At least, may make sense to rename "jetpack" object to "env" or similar

For the Jetpack team

  • Why was the Vapour-style use of markup abandoned?
  • What UI paradigms have been explored but didn't work?
  • What UI paradigms have not been implemented due to browser/platform limitations?
  • Is the security model held back by anything in the platform, or can it be fully developed as a separate component like it is currently?
  • Would it make sense to put all APIs in IDLs?
    • Potentially slower, but more secure.
  • How stable are Jetpack's APIs right now? Does it make any sense to include some of them in Firefox itself for Jetpack to use so we can handle changes as Firefox is upgraded rather than Jetpack having to cope?
  • Is Jetpack having to use any ugly or private means to get at the functionality it requires in the platform that it might make sense for us to expose in some stable API?
  • Is there any part of the security model that it would be helpful to uplift into Firefox and perhaps make available for add-on developers using the full XPI route to use if they want to keep things safer?
  • Have the Jetpack team thought much about uplifting into Firefox and how you envisaged that progressing in the future?

For the Firefox team

  •  ?