WebAPI/PlannedWork

NOTE

This is a backlog of ideas for potential future work. Nothing is committed until it lands in a release :) .

P1

Owned

• FuturePromises; owners: baku, mounir and annevk, bug 839064
• AudioChannel API; owners: baku and bent, bug 853101
• Storage: move appcache, cookies(?) and localStorage to centralized quota manager, owner: janv
• Storage: temporary/permanent storage for IDB, owner: janv
• Storage: IDB in workers, owner, janv
• inputmode: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-February/038914.html, owner: mounir
• storage.js, owner: mounir
• IME/Keyboard API, owner: mounir and others (Gaia and B2G)
• NavigationController, owner: ehsan

Need implementer

• Inter App Communication, design: mounir
• Data Store, design: mounir, sicking and others
• Improve appcache, design: sicking
  • Mozilla's proposal: http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0977.html
• Add a way to make the manifest file discoverable (via a manifest attribute or something similar), design: sicking, marcosc, mounir

Need design

• Sync API (sicking), eg. keep GMail synchronized
• System Messages on Desktop
• support shared workers and background workers explicitly for things like social API (?) (dougt)
  • support web pages and apps doing something in the background

P2

• Web Activities on Desktop

• Fix browser API (jlebar)
  • don't use iframe element
  • due to ^ can't load browser API when element is created
  • may want to rewrite in C++
  • Improve security checks
  • Support "nested child processes"

• Change <iframe mozbrowser> to <webview> (or whatever).
  • Right now the mozbrowser API doesn't get loaded until some time after the iframe is inserted into the DOM. This makes things difficult for clients who would like to be able to count on e.g. always being able to call setVisible().
  • When we make this change, we should look into converting mozbrowser into C++. Loading it currently has relatively high overhead, and we've put in a bunch of hacks to work around it.
  • If we do this, we should coordinate this HTML parser hack somehow and probably not expose it (and not reserve "webview" as a name for normal content).

• Getting back notifications after the page has been killed. Some links: [1] [2] [3]

• Storage: Sandboxed Filesystem

• navigator.language change event (W3C HTML Bug)
• API for generic LED actuators (usually camera LED, though some phones include additional ones)

P3

• Battery API v2 (temperature, voltage, etc.); the real world use cases are not clear but we might need that in FxOS soon enough and we should be ready

• Fix FM Radio API (jlebar)
  • doesn't behave sanely with multiple windows attempting to access it
  • will likely require major changes

• Contacts API in desktop, related permissions situation
  • We are planning to deprecate the current Contacts API so we should make sure that we keep that into consideration

• ArchiveReader prototype in Javascript
• Speech API
• Storage: Quota API
• Storage: Data-moving (temp -> perm)
• Keyboard layouts and gaming: KeyboardEvent.code (bug 865649) and KeyboardEvent.locale (bug ???) (smaug?)

Side track

• integrate better with profiling tools
  • work with SPS profiler people
  • IDB performance
  • for both B2G and Firefox
• Expose audio API to Firefox Desktop Internal code

• Build a Web API dashboard similar to chromestatus.com, see if we can integrate it with the devtools UI, and what other cool things we can do with it. (ehsan)
• tests
• resolving intermittent test failures
• worker-ification of existing APIs
  • make this easier