Firefox/Projects/Jetpack Uplift Exploration/Notes
Note: This assumes many things!
This describes a potential ideal scope, if Jetpack were to be shipped as part of Firefox.
- Development environment (separate addon)
- Code editor
- Firebug specific code
- 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
- Slidebar (replace/improve current sidebar functionality)
- JS security code (eg, securable membrane)
Subscription / Installation / Management
- Management through Extension Manager API and [[Extension Manager Redesign
- Install & update comparable to current addons
Areas where Firefox should provide simple APIs:
- URLbar icons
- Site identity pane (Larry)
- Doorhanger notifications
- Content context menu
- Statusbar panels (Note: may be removed in Windows Theme revamp)
- Main menu (Note: may be removed in Windows Theme revamp)
- Main toolbar
- Preferences UI
Further in the Future
- bug 492844 - ES5: Implement Object.freeze, Object.isFrozen
- ChromeObjectWrapper (landed on trunk)
- Transparent iframes
- Lightweight iframes? Need some efficient way of sandboxing and displaying untrusted markup/code.
- Scriptable HTML parser (@mozilla.org/xmlextras/domparser;1 only handles XML)
Note: Not specific to Jetpack.
Provide utility libraries similar to FUEL but for non-browser stuff. For browser-related functions, FUEL can be expanded.
- 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
- 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
- Complete security model
- Stabilize code
- Test for vulnerabilities
- Unit test coverage
- Inclusion of metadata in Jetpacks
- 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
New Extension Manager API and UI
- Jetpacks would fit great as first class citizens here, alongside current addons. The new API will make that possible, and the UI will make it doable.
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.
- New UI to hook into.
- 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