Platform/Roadmap2012

From MozillaWiki
Jump to: navigation, search


Tempicon.png Firefox Platform 2012 Roadmap
Owner: Chris Blizzard Updated: 2014-12-9
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.


Vision

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

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

Name Description Status When Who
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 <thead> </thead> <tbody> </tbody>
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
}

Apps

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.
Name Description Status When Who
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 <thead> </thead> <tbody> </tbody>
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
}

Devices

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.

Name Description Status When Who
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) <thead> </thead> <tbody> </tbody>
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

Layout

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.

Name Description Status When Who
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 <thead> </thead> <tbody> </tbody>
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

Media presents one of the most interesting areas where there's opportunity to build something amazing. These fall into a few areas of note:

  1. Enabling games. Mozilla's Full Screen API, which is also being implemented in other browsers, is useful for everything from watching videos to playing games. When you combine video, WebGL, fast JavaScript and the Mouse Lock API you end up with something that can create everything from small social games to first person shooters.
  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.
Name Description Status When Who
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 <thead> </thead> <tbody> </tbody>
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
}

Tests

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.

Name Description Status When Who
Finish tests on html5test.com It's used as a proxy for HTML5 support in order to rate browsers. Ongoing All through 2012 <thead> </thead> <tbody> </tbody>
Everyone
Finish test on areweplayingyet.org (bug 700208)
It's used as a proxy for HTML5 audio support.
Ongoing
All through 2012
Everyone
}