WebAPI

The Mozilla WebAPI team is pushing the envelope of the web to include --- and in places exceed --- the capabilities of competing stacks.

Contributing

WebAPI work is being tracked by Mozilla bug 673923. Find a dependent bug that interests you (and is unassigned), and assign it to yourself.

Documentation

This wiki page's purpose is mostly to be able to track the advancement of the work on the different APIs covered by the WebAPI team and help working on those. If you are interested in documentation for these Web APIs, you should look at the following MDN documentation page: https://developer.mozilla.org/docs/WebAPI

APIs

Here's a list of the APIs that we're working on. Some of them are done, and some of them we haven't gotten further than acknowledging that we probably need them.

Planned for initial release of B2G

Unless otherwise noted, APIs listed in the table below were available in Firefox OS v1.0.1 or will be available in v1.1.

Planned for the future

Legend

Process

A draft specification and prototype implementation of new Web APIs will be discussed publicly on our mailing list and at our public meetings (see below). Once we have an API that we feel that we are satisfied with, we will submit the new API for standardization to the W3C. See also tips for standardizing APIs.

The goal is to standardize all APIs.

Design Principles

Security

Security will be a central aspect of all the APIs that we design. We wouldn't want any random webpage to be able to read the user's contact list, or able to issue arbitrary commands to any USB device which is hooked up to the user's computer.

In some cases the solution will be to simply ask the user, like we do today for Geolocation for example. In other cases, where security implications are scarier or where describing the risk to the user is harder, we'll have to come up with better solutions. For example, enumerating sensitive information or exposing device specific configuration to the web can be avoided by implementing dialogs (like the file picker for <input type=file>). Those can be implemented in the platform and ask the user which information to expose to the current website specifically.

This is an area where we're still doing a lot of research. I really want to emphasize that we don't have all the answers yet, but that we plan on having them before we roll out these APIs to millions of users.

Low Level vs. High Level

One question that often comes up, is should we do low level APIs, like USB access, or high level APIs, like camera access?

In many cases we are going to want to do both high level and low level APIs, with an initial priority on low level. High level APIs will let us create more friendly APIs, which are both easier to use for developers, and better for users since we can provide better security guarantees. However low level APIs will provide support for a wider range of hardware and use cases and will get the browser out of the critical path for innovation.

Plans

• Old planning document
• Old (2013) storage discussion notes

Meetings

We used to have weekly meetings but as of 1 October 2014 we no longer do.

If there's something you'd like to discuss, ask on dev-platform. Since much of this effort is under Mozilla's DOM team, #content isn't a bad place for IRC conversation.

Meeting Notes

See also

• Introducing WebAPI blog post by Robert Nyman
• More details about the WebAPI effort blog post by Jonas Sicking
• Mozilla joins the W3C DAP – WebAPI progress blog post by Robert Nyman and Jonas Sicking
• A look at the latest WebAPIs a demo/blog post by John Hammink

Demos

• Battery API by Robert Nyman
• Vibration API by Robert Nyman
• Demos by John Hammink
• Network API by Colin Frei

Other efforts

• W3C Device APIs (DAP). Mozilla developers are members of the DAP working group (announcement).
• Wholesale Applications Community (WAC)

Subpages of WebAPI