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 and bug 876631
• 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, bent
• inputmode: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-February/038914.html, owner: mounir
• Service Worker, owners: nsm, bkelly, baku
• Inter App Communication, owners: mounir, gene, ferjm

Need implementer

• 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
  • https://github.com/slightlyoff/BackgroundSync/ ?
• 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 - https://github.com/slightlyoff/BackgroundSync/ ?

P2

• Web Activities on Desktop

• Fix browser API (Kan-Ru (?))
  • 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
  • http://w3c.github.io/filesystem-api/Overview.html

• 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
  • 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 (smaug has been involved and Andre Natal has been implementing)
• Storage: Quota API (janv)
• Storage: Data-moving (temp -> perm) (janv, bent)
• 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

Untriaged

• URL parsing
• base URLs
• find and findAll methods
  • needs special subclass of JS array
• Shadow DOM (wchen is working on this)
• Fetch + Service Worker (annevk continues to work on spec and nsm, baku, and bkelly are implementing)
  • lots of questions here (e.g. iframes, workers)
• delayed delivery of DOMContentLoaded eventdecided this wasn't useful
  • after IDB data has been loaded
  • allows for synchronous querying of data in <script blocks
  • Ben says this isn't related: https://docs.google.com/document/d/1EGM9xmQXbJ_rI0IFhbnACiDaaBPTSb7T3RynwD-naJg/edit?hl=en&authkey=CO7aqZAO#
• Jonas' plans around necko threadsafety (notably URI/URL)
• Web Push (bug 1024730)
  • SimplePush is the existing non-standard API we have now
  • Web Push will be implemented by other browsers and be cross-platform
  • Web Push requires Service Workers
• landing some in-process work
  • Broadcast Channel (bug 966439)
  • MessagePort and MessageChannel (bug 741618, bug 911972)
  • finish Blob porting (bug 1047483)
• DataStore in workers (rewrite in C++: bug 990554)