Platform/Roadmap: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
Line 2: Line 2:
|icon=Tempicon.png
|icon=Tempicon.png
|pagelocation=Platform/Roadmap
|pagelocation=Platform/Roadmap
|pagetitle=Platform 2011 Roadmap
|pagetitle=Firefox Platform 2012 Roadmap
|owner=Chris Blizzard
|owner=Chris Blizzard
|updated=August 2011
|updated=January 2012
|status=Awesome
|status=Awesome
|description=This roadmap outlines the current strategy and direction for Mozilla Platform development through 2011.  While much of the recent past has been focused on HTML5, it's become obvious that where we want the web to go has to go well beyond that and build something that moves the web forward in a way that takes advantage of its unique capabilities, and will allow you to move seamlessly from phones to tablets to your desktop.
|description=This roadmap outlines the current strategy and direction for Mozilla Platform development through 2012.  It mostly covers new developer-facing APIs.  Work on [https://wiki.mozilla.org/Performance/Snappy performance] and reliability is done elsewhere.
}}<section end="summary" />  
}}<section end="summary" />  


=Platform for Firefox=
= Vision =


The vision for Firefox has been outlined in [https://wiki.mozilla.org/Firefox/VisionStatement Jay’s Vision for Firefox document]. That document is extensive, but boils down to a simple vision:
'''We want the platform in Firefox to enable app-quality experiences and developer productivity that rivals native platforms.'''


'''Discover, experience and connect with apps, websites and people on your own terms, anywhere.'''
= Networking =


It’s the Platform team’s job to support that vision with engineering resources and process. This document will attempt to lay out the first set of priority items that we should be investing in.  This document is not exhaustive, but should reflect where people should look for “next steps.”
{| class="fullwidth-table"
!Name
!Description
!Status
!When
!Who
|-
| [https://bugzilla.mozilla.org/show_bug.cgi?id=695635 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
|-
| [https://wiki.mozilla.org/Platform/Features/SPDY 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
|-
| [https://bugzilla.mozilla.org/show_bug.cgi?id=702122 DASH WebM Support]
| This adds support for adaptive streaming for video with the WebM codec.  It's based on the [http://sourceforge.net/apps/trac/matroska/wiki/DASH_Profile WebM + DASH spec].
| Work underway
| Work underway in Q1.  Delivery based on spec stability and feedback, but hopefully in Q2.
| Networking & Blizzard
|-
| [https://bugzilla.mozilla.org/show_bug.cgi?id=264354 HTTP Pipelining]
| This adds support for HTTP pipelining to desktop browsers by default.  HTTP pipelining offers a [http://bitsup.blogspot.com/2010/11/performance-of-pipelining-in-http.html 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
|}


The Platform underlies much of what we do, and as such our goals are to help our products shine.  Here’s what the platform needs to do:
= Apps =


* We need to make Firefox awesome.
{| class="fullwidth-table"
* We need to make Web Pages awesome.
!Name
* We need to make Apps awesome.
!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
| 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 & hason)
| 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 these may seem flippant, it’s important to remember that these are our main audiences.  Whether or not they are delivered via a software download, a service or someone else’s creation we need to create an environment where all of these can flourish.  This roadmap will try to cover the next steps for these three areas.
= Devices =


== Making Firefox Awesome ==
See also: [https://wiki.mozilla.org/WebAPI the WebAPI page.]


Firefox is the main tool we have to create the web we want.  In order for people to choose Firefox, we need using it to be an amazing and engaging experience.  This means delivering a good blend of simplicity, extensibility and performance.  All audiences will be looking for this.  But we’re interested in early-to-middle adopters, which means we should be focused on more cutting edge features that can also be adopted by web sites in order to improve the experience of users at the leading edge.
{| class="fullwidth-table"
!Name
!Description
!Status
!When
!Who
|-
| [https://wiki.mozilla.org/Platform/Features/Camera_API Taking a picture]
| This lets a web page take a picture using the built-in camera for the device or PC.
| Works on Mobile.  Does not work on Desktop.
| Q2 (maybe)
| Media & DOM & Firefox & Maire
|-
| [https://wiki.mozilla.org/Features/Platform/OfflineApps 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 am 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 isn'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
|}


=== Making Firefox Fast ===
[https://wiki.mozilla.org/WebAPI 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


We have to make Firefox fast.  It must be able to compete with other browsers on benchmarks and must feel incredibly responsive to user input.  We should also be investing in ways to make existing web pages and web applications faster with newer versions of the browser.
= Layout =


'''Key Measurements''' (Note: All of these should be compared to other browsers!)
Please also see the [https://wiki.mozilla.org/Platform/Layout#Feature_Planning Layout Feature Planning Page].
{| class="fullwidth-table"
!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
| David Baron & Mobile & Blizzard
|-
| [https://bugzilla.mozilla.org/show_bug.cgi?id=702508 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 flex.
| Layout & Blizzard
|-
| CSS Grid
| This adds grid layout support to our layout engine.  Something well-known in the design community.
| Not started
| Start in Q1
| Layout & Blizzard
|-
| CSS Regions
| Add support for CSS Regions to the layout engine
| Not started
| Later in 2012
| Layout & Blizzard
|-
| CSS Exclusions
| Add support for CSS Exclusions to the layout engine
| 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
|}


* How responsive is the browser during intense moments like a tab restore after start up?
= Media =
* How fast can we load and render web pages? (priority)
* How fast can we start up? (priority)
* How fast can we create new windows on demand?
* How fast can we react visually to people’s mouse movements and button presses? (priority)
* How do we compare to other browsers on industry benchmarks?


'''Projects:'''
{| class="fullwidth-table"
!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
| Blizzard & Media
|-
| 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
| Demo in Q1
| 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.
| Underway
| Demo in Q1
| Blizzard & 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.
| Underway
| Later in 2012
| Humphd & Blizzard & Media
|-
| 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
| Blizzard & Media
|}


Measurement & Performance
= Tests =
 


* Telemetry - Ongoing heuristics and measurement
{| class="fullwidth-table"
* 50ms response time project
!Name
* Tools for measuring Networking Performance
!Description
!Status
!When
!Who
|-
| Finish tests on html5test.org
| It's used as a proxy for HTML5 support in order to rate browsers.
| Ongoing
| All through 2012
| Everyone
|-
| [https://bugzilla.mozilla.org/show_bug.cgi?id=700208 Finish test on areweplayingyet.org]
| It's used as a proxy for HTML5 audio support.
| Ongoing
| All through 2012
| Everyone
|}


Networking
* SSL Fast Start
* SPDY (low risk, medium reward)
* Web Timing Specs
* Pipelining (high risk, high reward)
* HTTP Pre-connections
* Cache Priorities
* Cache Control APIs
JS
* IonMonkey - better perf, platform for research and future perf improvements
* Debug API - so people can build faster apps and save time in Firefox
* Incremental GC - perf and getting rid of pauses
* Generational GC - same, but different tech
* Type Inference - performance & infrastructure for more measurement
* Profiler - required to let people optimize JS code and make it faster
* Objshrink - better performance and lower memory usage
* ES.next modules - faster access through better interfaces for web developers
* Runtime optimizations - better performance
* Refactoring & cleanup - for security and performance
DOM
* New DOM bindings
* Pre-cached JS libraries (hash? cache?)
* Steaming XHR interface instead of download/process
* HTML5 App Cache Replacement / Caching API
GFX
* GL for Mobile
* Azure
* NPAPI Async Drawing
* Electrolysis Accelerated Layers
Devtools
* Tools for external web developer profiling (see Page Speed)
* Tools for internal profiling
Electrolysis:
* Make it go
=== Making Firefox Reliable ===
Key Measurements:
* How often does Firefox crash?
* How often does Firefox hang?
* How often do plugins crash?
* How often do plugins hang?
* How often do we survive a content crash?
* Does Firefox’s memory usage cause the rest of the system to slow down?
* How often do people using Firefox have network problems?
* How often do people have problems rendering web sites?
* What’s our overall user satisfaction numbers with Firefox’s reliability?
Projects:
Tools:
* Capturing browser hangs
Engineering:
* Crash kill
* Telemetry
* Electrolysis
* MemShrink
Plugins:
* Moving plugins destroys & re-creates them instead of just moving them
* Key events aren’t properly passed between chrome and plugins
* Better API for plugin rendering
=== [https://wiki.mozilla.org/Security/Roadmap Keeping Firefox Secure] ===
Key Measurements:
* Days of exposure for our users?
* How much lag time do we have for incoming security requests?
* Are we perceived as being secure in the market?
* Are the number of zero days and reported exploits going down with time?
* Are we getting security reviews done in reasonable time and at the right time in the feature lifecycle?
* Are we shipping releases with no sg:crit or sg:high bugs?
Clean-up and fixes
* Sandboxing of content processes
* Plugin background updating
* Plugin sandboxing
* ...
Security Innovation
* DNSSec
* UX Security experiment
* CSP revisions
* [https://wiki.mozilla.org/Security/Features/XSS_Filter XSS Filter]
* ...
=== Market / Engine Match (Keep Gecko Great) ===
Key Measurements (Largely subjective):
* Do we compete with WebKit and the IE rendering engine on our ability to add new features?
* Are we able to take advantage of the best capabilities offered by a hardware platform and operating system?
* Is our engine perceived as being great?
* Are we set up for future directions in hardware development?
* Does our engine give us the tools to fit market needs?  Future market needs?
* Are we able to make performance and architecture improvements easily?
Projects:
Engineering:
* Maintain a moden graphics stack
* Improve readability and quality of our code base to attract external contributors
* Support for multi-core
* Support for mobile
* Support for security
* Support for network encryption improvements
== Making Web Pages Awesome ==
It’s not enough that we make the experience of using Firefox great.  We must also keep pushing the web technology forward so people can make more beautiful & functional web sites.
Note that many of these items overlap with the section below on Making Web Applications Awesome.  When in doubt, assume that functionality will be available to both.  This section deals more with display & device integration technology for the web.
Key Measurements:
* Are people adopting technology as we deploy them?
* Are our competitors adopting them as well?
* Are we adopting great ideas and standards from our competitors?
* Is Firefox seen as dragging the web forward?
* Are we equivalent to mobile platforms in display, animation and device integration?
* Are we making it possible to build apps that are more beautiful and faster?
=== Getting the best from Fonts ===
* Continuing to implement the new CSS Font standards
=== Improving the state of Display Technologies ===
* Support for text-overflow: ellipsis (Shipped in Firefox 7)
* Support for CSS Hyphens
* Support for CSS Animations (Shipped in Firefox 5)
* Support for 3D transforms
* Support for CSS Flex
* Support for CSS Grid
* Support for CSS Regions
* Support for Veritcal Writing
* Better control over color matching
* CORS Support in WebGL
* WebGL anti-aliasing
* WebGL full 1.0-compliance
=== Making Moving Media a First-Class Citizen ===
Media & Layout:
* Metrics API for HTML5 video performance
* Support for Full-screen applications
* Integrated media APIs for capture, upload and real-time communications
* Real-time Video and Audio Communications in the Browser
* Adaptive bandwidth support for HTML5 video
* Support for HTML5 video looping
* Adding support for hardware decoding, where available
DOM:
* Connecting media sources to worker threads for processing
=== Support for Programming at Scale ===
DOM:
* Fine-grained support for loading and compiling JS libraries
* Load-complete and error events for CSS, font and JS files
* Shared Workers for cross-tab communications
=== Finish HTML5 support ===
DOM:
* Complete HTML5 forms
* HTML5 Form Events
* Finish worker pools
* Dynamic markup insertion
* Labels properties on fields
* Microdata (?)
* FileWriter API (no?)
* Shared Workers
* Seamless iframe
* Sandboxed iframe
Media:
* Timed track support
=== Full Device Integration ===
Media:
* Support for Taking a Picture (build instagram)
* Support for capturing and uploading a video file with HTTP
DOM:
* Electrolysis for IndexedDB (multiple processes)
* Support for uploading a Directory with relative pathnames preserved
* Exposing Libraries or Directories as a file tree
* Passing Files & Directories into Workers
* Ability to drag files out of a web page with download_url
* EventSource for Workers
* IndexedDB for Workers
* WebSockets for Workers
* Touch and Multi-touch support
* Better support for scrolling (Joe Hewitt’s Scrollability)
Identity
* Verified email
* Contacts
== Making Apps Awesome ==
Key Measurements:
* Can we load a Web Application in less than 100ms?
* Do people feel it’s OK to pay for things on the web?
* Are developers making money on the web platform through direct payments?
* Are developers and companies building apps on the web?
* Do users feel that the experience of using a web app is on par with a native app?
'''Vision for Apps Platform'''
( need to pull from Ragavan / Jay based on vision document and their work
=== Improve the Experience of Using Applications ===
Firefox:
* [http://areweprettyyet.com/5/desktopApps/# Site-specific Windows]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=617528 Support for context menus that look native, but are under app control]
* How do I take my applications with me across all my devices?
* How do I share from inside of an application?
* How do I advertise capabilities from inside of an application?
=== Making it Possible to Pay for Applications ===
* Monetization (One-time buy / subscription / in-app purchase)
* Downloadable
* Install Process
* Receipts / End-user Ownership Verification / Entitlement
=== Make it Possible to Find Applications (not platform) ===
* Discovery while browsing
* Social recommendations - how do I share an application?
* Search
* Opportunistic / Heuristic discovery
* Rough location / “in a business.”
* Required applications (ex. HIPAA)
=== Support for Applications Without Windows ===
* Messaging & Notification APIs for Desktop
* Messaging & Notification APIs for Mobile (SMS or other mobile integration)
* Support for Worker activiation on receipt of a message from the Web
* Ability for Workers to create pages after processing a message
* The ability to deliver a message to an open app or web page.
=== Make Web Apps First Class Applications ===
* Remove cross-site access restrictions for installed applications
* Easy access to cameras, microphones and other hardware (examples)
* User-friendly security model that matches expectations of security and privacy
* Access to OS-level data for apps (contacts, etc)
=== Have Great Development Tools for Applications ===
* Idea to deployment in 20 minutes.


[[Category:Roadmaps]]
[[Category:Roadmaps]]

Revision as of 01:02, 25 January 2012

Tempicon.png Firefox Platform 2012 Roadmap
Owner: Chris Blizzard Updated: 2012-01-25
This roadmap outlines the current strategy and direction for Mozilla Platform development through 2012. It mostly covers new developer-facing APIs. Work on performance and reliability is done elsewhere.

Vision

We want the platform in Firefox to enable app-quality experiences and developer productivity that rivals native platforms.

Networking

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 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. Work underway Work underway in Q1. Delivery based on spec stability and feedback, but hopefully in Q2. Networking & Blizzard
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

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 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 & hason) 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

See also: the WebAPI page.

Name Description Status When Who
Taking a picture This lets a web page take a picture using the built-in camera for the device or PC. Works on Mobile. Does not work on Desktop. Q2 (maybe) Media & DOM & Firefox & Maire
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 am 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 isn'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

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 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 flex. Layout & Blizzard
CSS Grid This adds grid layout support to our layout engine. Something well-known in the design community. Not started Start in Q1 Layout & Blizzard
CSS Regions Add support for CSS Regions to the layout engine Not started Later in 2012 Layout & Blizzard
CSS Exclusions Add support for CSS Exclusions to the layout engine 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

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 Blizzard & Media
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 Demo in Q1 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. Underway Demo in Q1 Blizzard & 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. Underway Later in 2012 Humphd & Blizzard & Media
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 Blizzard & Media

Tests

Name Description Status When Who
Finish tests on html5test.org It's used as a proxy for HTML5 support in order to rate browsers. Ongoing All through 2012 Everyone
Finish test on areweplayingyet.org It's used as a proxy for HTML5 audio support. Ongoing All through 2012 Everyone
Retrieved from "https://wiki.mozilla.org/index.php?title=Platform/Roadmap&oldid=390162"