Firefox/Projects/Jetpack Uplift Exploration/Notes: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
Line 103: Line 103:
** Potentially slower, but more secure.
** Potentially slower, but more secure.
* Would uplift include renaming?
* Would uplift include renaming?
** Jetpack is a good code name, but maybe not a feature name
** 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
** At least, may make sense to rename "jetpack" object to "env" or similar
* Jetpack has been producing a set of APIs for feature developers to use. How stable are these 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?
* Jetpack has been producing a set of APIs for feature developers to use. How stable are these 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?

Revision as of 13:46, 20 July 2009

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

Included

  • 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

Uplifted separately

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

Subscription / Installation / Management

  • Management through Extension Manager API and UI
  • Install & update comparable to current addons

Platform requirements

Browser UI

Areas where browser.xul/browser.js should provide simple APIs:

Extension Manager

Javascript / Sandboxing

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

Layout

  • 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)

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

  • https://wiki.mozilla.org/Firefox/Sprints/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

Questions

  • 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.
  • 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
  • Jetpack has been producing a set of APIs for feature developers to use. How stable are these 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?