|Firefox Platform 2012 Roadmap|
|Owner: Chris Blizzard||Updated: January 2012|
|This roadmap outlines the current strategy and direction for Firefox Platform development through 2012. It mostly covers new developer-facing APIs. Work on performance and reliability is done elsewhere.|
This roadmap covers the surface area that we will expose to web developers in order to let them build the next generation of web applications. Overall our vision for Firefox's role in the web ecosystem is:
We want the platform in Firefox to enable app-quality experiences and developer productivity that rivals native platforms.
This roadmap covers the high-priority items that we should accomplish during 2012 in order to achieve this goal. We've broken the list of items roughly down by domain area, with small amounts of context around each one.
Networking covers several areas that are important to improving experiences in web browsers. In particular, there's a decent amount of work that can be done to improve performance. During 2012, we would like to be able to deploy SPDY, which offers significant performance improvements to end users on sites with many resources, as well as better resource management for servers.
While SPDY's benefits are useful for sites that have SPDY-capable servers, most of the rest of the web still will run off HTTP for the foreseeable future. We've got some innovative ideas around how to deploy HTTP Pipelining, which would give many of the benefits that we can get with SPDY, but that will actually work with most of the web as its deployed today. Users will definitely be able to feel improvements from HTTP pipelining, especially for anyone using a high-latency mobile connection or over a trans-oceanic link.
In addition, in order to support a richer and more seamless media experience there's work that needs to be done to support the emerging DASH-for-WebM standard. This will let the browser and server adapt to changing network conditions, start a video faster and adapt quickly to changes in resolution. (Like, when you change from in-a-page to full screen.)
|Compete WebSockets to Match RFC||This brings WebSockets to the point where it matches the IETF RFC. It includes the protocol and API bits from the W3C.||Done||Done||Networking & Blizzard|
|Support for SPDY||SPDY is a new protocol built on the request app model of the web that allows for multiplexing, connection sharing and is SSL-only. It saves costs for server vendors who will have to deal with fewer connections per page load. And for end users it makes pages generally feel faster to load.||Checked in for testing, not enabled by default.||Testing in Q1, deployment depending on feedback.||Networking & Blizzard|
|DASH WebM Support||This adds support for adaptive streaming for video with the WebM codec. It's based on the WebM + DASH spec. (This is largely a Media project that Networking has graciously taken on on behalf of both teams.)||Work underway||Work underway in Q2. Delivery based on spec stability and feedback, but hopefully in Q3.||Steve Workman, Jason Duell, networking & Maire|
|HTTP Pipelining||This adds support for HTTP pipelining to desktop browsers by default. HTTP pipelining offers a significant page load performance win especially over higher-latency connections (like mobile or any trans-oceanic connection.) The risk here is medium, as the patches have excellent back-off characteristics but pipelining has historically been considered to be difficult to implement. Pipelining is actually used on most mobile devices, but hasn't been turned on in desktop browsers to date.||Has patches||After SPDY is done.||Networking & Blizzard|
|HTTP Pre-connections||Adding support for pre-connections would open HTTP connections ahead of page loads or after search results under the assumption that users will always go to the same sites.||Not started||After pipelining.||Networking & Blizzard|
There are a lot of tasks around Apps that need doing. These fall into a few major categories:
1. Enabling a developer ecosystem. The first part of this is to allow users to take control of their identity in a way that fits with the decentralized model of the Internet. (This is useful to web sites as well, not just in the context of apps!) This identity can then be used to prove that they have paid for various items, software or services.
2. Enabling a great experience for users with applications. While apps will be based on an HTML5-based platform and should run in any browser, there are several items where the experience should be better with Firefox (or any other browser that implements the same functionality.)
3. Application communication and intergration. With Intents (and previously Mozilla Activities) it should be possible for the web to grow with each application that is added. That is, each application doesn't have to be something that stands alone, but instead can be used by other applications to enable new and interesting functionality.
4. New capabilities. Items like raw socket access, HTTP without cookies, background tasks and a notifications system are all things that are available to native applications. Installed applications (not necessarily web pages) should have these privileges as well.
|Identity (Verified Email)||This gives us the ability to assert that an email address has been verified, which is a proxy for identity. This has its own roadmap, but is worth mentioning because it's an important part of the overall roadmap for the rest of the apps platform.||First stage already deployed, with more UI coming in later quarters.||Q1||Dan Mills|
|Receipts||Receipts allows you to assert that a particular identity has paid for a service or item.||Underway (Jennifer)||Q1?||Dan Mills|
|Install process for Apps||An install process allows you to install an app into your browser or into your operating system.||Underway||Q1?||Jennifer|
|Make App Cache opportunistic for Firefox Desktop||This makes the app cache act much like our current cache, in that it has a bounded size and will expire old data. It also means we don't have to ask the user for permission to install something without context. This is useful in the browser context.||Waiting||Q2||DOM & Media & Blizzard|
|Updates to the App Cache||We need to update the App Cache to make it work better in many situations that have been identified since the original specs were written. This includes support in the face of CDNs, extra APIs, etc.||Scoping||Q2 to finish scoping and start work||DOM & Networking & Blizzard|
|Improve Register Protocol Handler||We need to improve our register protocol handler for Apps.||Unknown (Ben)||?||DOM & Ben|
|Replacement for Web Intents||Web Intents allows applications to register themselves to handle actions and content. The current spec is apparently quite large and complicated and never got off the ground. So it needs re-visiting.||Unknown (tantek & hanson)||Maybe start in Q1?||Tantek & Hanson|
|Install trigger - Scope in Q1||In order to support installations we need the ability for a web site to trigger an install. This is essentially part of our store functionality.||Scoping||Q1||Hanson|
|Push Notifications||Push notifications allow us to push data to installed apps on people's computers and browsers. This would be a pretty major change to the architecture of the web, is closely and would need background tasks and and activation system to support it. These would only be available to "installed" apps.||Unscoped||Later in 2012||Blizzard|
|Background tasks||Background tasks are things that apps can do in the background. These things could be the result of a push notification, network event or a timer that's running. They would only be available to "installed" applications, but could prove very useful.||Unscoped||Later in 2012||Blizzard|
|Low-level Socket API||One thing that's oft requested (especially for games) is a low-level read/write socket API that's available for installed apps. Native platforms can do this easily. This would not be available to untrusted applications/web pages.||Unscoped||Later in 2012||DOM & Networking & Blizzard|
|Open HTTP without cookies||One thing that's often requested by app developers is the ability to make arbitrary HTTP requests that don't share the cookie state with the browser. This is similar to the low-level socket API but is HTTP-specific. Another way to describe this: getting rid of the cross-domain restrictions for installed applications. This would not be available to untrusted applications/web pages.||Unscoped||Later in 2012||DOM & Networking & Blizzard|
While it's important to build a developer ecosystem to enable payments and a great install experience it's also important that we enable a set of web APIs for access to devices connected to a computer, tablet or phone. This includes everything from access to an NFC device, to offline storage to raw touch events from your tablet.
See also: the WebAPI page.
|Taking a picture||Backend support for taking a picture or creating a camera app (like for B2G)||Will be targeting for B2G initially (as part of basecamp) and then will target desktop and android||FF15 (B2G), FF16 (desktop, Android)||Anant & Fabrice & Maire & Media & DOM & Firefox|
|Finish IndexedDB||This completes the changes that happened to the IndexedDB spec and working on performance problems.||Done||2011Q4||Blizzard & DOM|
|Upload a Directory||This lets you pick a directory and make it available to both File APIs or upload directly. It should maintain the subtree structure in the original filesystem.||Not started||Q2||Hanson, DOM & Blizzard|
|Access to Local Media Storage (including USB)||This gives access to local media for permitted applications and web pages to upload, sync, or otherwise access. This should be similar to the way that we upload files now, and eventually directories. It just flattens access across devices, PCs, phones, etc. Includes music, pictures and video.||Not started||Q2||Hanson, DOM & Blizzard|
|Drag files with download_url||Chrome includes the ability to mark an a href with a download_url. You can then drag that link to your desktop and the file is downloaded from the URL.||Not started||Later in 2012||DOM & Blizzard|
|Finish touch and multi-touch||We've done some first-pass touch APIs for Windows 7 and mobile. The multi-touch support and gesture support aren't done yet, so we need to finish them. This will be true for Windows 7 and Android.||Unknown||Later in 2012||DOM & Mobile & Firefox & Blizzard & Sicking|
B2G APIs (Not managed here.)
Dialer (B2G) - Underway Network Status (B2G) - Underway Vibration (B2G) - Underway Battery (B2G) - Underway Contacts (sicking & B2G) - Underway Ambient Light (B2G) - Q2 Proximity to Your Face (B2G) - Q2
In the area of layout we need to enable a bunch of new ways to express layouts that designers have used through other tools for years. These include flexbox, which is very similar what what we've been using to layout the Firefox UI for years, Grid and Regions & Exclusions. All of these enable new kinds of experiences.
We also need to enable Gecko to run on Mobile devices. This means that we need to lay out pages with fonts in a sane way and enable spring scrolling for touch devices.
Please also see the Layout Feature Planning Page.
|Readability / Font Size inflation||This is the ability to resize text for mobile devices based on the size of the screen and the reasonable minimum size for text.||The main layout parts of this were done in Q4 of 2011. There's still some additional work being done in Q1 based on the feedback we've seen.||Q1||David Baron & Mobile & Blizzard|
|CSS Flexbox||This adds support for something like the XUL box model to the web. It's being implemented in other browsers. It's very important for app layouts and will be a huge upgrade for the web.||Work underway||Q1 for single-line flexbox, Q2 for multi-line. Spec is still in a bit of flux.||Layout & Blizzard|
|CSS Grid||This adds grid layout support to our layout engine. Something well-known in the design community. Our work must start with feedback on the current spec.||Not started||Start after Flexbox||Layout & Blizzard|
|Magazine-style layouts||Render text around images and other complex interactions with entities in web pages. This may be CSS Regions & Exclusions, or alternative proposals. The current W3C specs still need significant work in order to address the important use cases before they can be implemented.||Not started||Later in 2012||Layout & Blizzard|
|@page support||Add support for @page||Not started||Later in 2012||Layout & Blizzard|
|ruby support||Add support for HTML5 ruby||Not started||Later in 2012||Layout & Blizzard|
|Spring Scrolling Support||Add support for spring scrolling||Not started||Later in 2012||Jonas & Blizzard|
|Scrolling APIs||Add support for decent scrolling APIs||Not started||Later in 2012||Jonas & Blizzard|
Media presents one of the most interesting areas where there's opportunity to build something amazing. These fall into a few areas of note:
2. Combining media. The media stream APIs make it possible to combine HTML5 video, real time communications, audio generation, audio manipulation and all kinds of interesting media experiences. This is useful for games, but will also be useful for presentation software, video editing applications and new kinds of media experiences.
3. Real Time Communications. The emerging set of standards around WebRTC is the first time we'll see browsers being able to communicate with each other without all communication being routed through some kind of 3rd party server. While most of WebRTC will be audio & video, we're also building a data channel to go along with audio and video. This means that you will be able to build applications and games that save bandwidth and have low latency by avoiding the extra round trip required by a 3rd party server.
|Full Screen Support||This lets any element on the page go into full screen mode. It's useful for watching HTML5 videos, full screen games, simulations, or anything else that you want to immerse yourself into.||Done||Q4, 2011||Blizzard & Media|
|Better Support for Capturing Keys in Full Screen Mode||We need to find a better way to allow key input in DOM full-screen mode. We need to allow enough key input to be useful for HTML5 games while minimizing the security risk.||Done||FF15||Chris Pearce, Maire & Media|
|Mouse Lock||This compliments the full screen APIs and lets you use the mouse as a controller instead of as a pointing device. Good for first person shooters, simulators, etc. The implementation of pointer lock and Element.mozRequestFullScreenWithKeys() (bug 716107) are going to conflict. Makes sense to track this with Bug 716107 (immediately above).||Done||FF14||Humphd & Maire & Media|
|DASH WebM Support||See NETWORKING section above for details||See above||See above||Maire & Networking|
|WebRTC||This is support for real time, audio, video & data communications between two browsers. The connections are point to point, with only the initial rendezvous between clients via a server.||Underway||Implementation target - Q3||Maire & Media|
|Media Stream Processing APIs||This adds support for media processing, chaining and processing that unifies the Audio Data / Audio Web APIs, video, RTC and other related items into a single useful API. Immediately needed for WebRTC support. So initially it's being tracked with WebRTC (immediately above).||Done||FF15||Maire & Media|
|Camera API (Taking a Picture)||See "Taking a Picture" in the "Devices" section above||See above||See above||Media & DOM & Firefox & Maire|
|Platform Decoders||Uses system codecs on a device to play an encoded audio or video file||Underway||Targeting Q2 for B2G, Targeting Q3 for Android, Desktop support is still TBD||Rob, Chris Double, Chris Pearce, Edwin, & Maire|
|Video Capture & Upload||This is the ability to record a video locally and upload it to a server once it's recorded.||Not started.||Later in 2012||Maire & Media|
We started to ship parts of HTML5 in Firefox 3.5 The spec has moved since then, and there are still some small parts we need to finish. These are often tested on sites as a kind of proxy for standards support and we should invest in finishing where it's appropriate.
|Finish tests on html5test.com||It's used as a proxy for HTML5 support in order to rate browsers.||Ongoing||All through 2012||Everyone|
|Finish test on areweplayingyet.org (bug 700208)||It's used as a proxy for HTML5 audio support.||Ongoing||All through 2012||Everyone|