WebAPI/PlannedWork

NOTE

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

• DOM Futures
  • http://dom.spec.whatwg.org/#futures
• Inter App Communication
• storage.js
  • as implementation solidifies, will want input from Gaia, others
  • related: https://wiki.mozilla.org/WebAPI/Storage2013
• appcache
  • Jonas' proposal: http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0977.html
  • Alex Russell's work: https://github.com/slightlyoff/NavigationController/
• audio manager API (baku)
• 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).
• 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)
• 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"
• Fix FM Radio API (jlebar)
  • doesn't behave sanely with multiple windows attempting to access it
  • will likely require major changes
• Sync API (sicking)
  • ex. keep GMail synchronized
• URL API (sicking)
• Storage
  • Sandboxed Filesystem
  • Quota API
  • Data-moving (temp -> perm)
  • move appcache and localStorage to centralized quota manager
    • also cookies
  • speak with necko team about disk cache work
• support shared workers and background workers explicitly for things like social API (?) (dougt)
  • support web pages and apps doing something in the background
• do we still want to change the security model of workers as sicking at some point suggested?
  • loading has same-origin limitation
• worker-ification of existing APIs
  • make this easier
• Expose audio API to Firefox Desktop Internal code
• integrate better with profiling tools
  • work with SPS profiler people
  • IDB performance
  • for both B2G and Firefox
• Bluetooth work may have fallout work (Team Ben)
• clean up rich text editing
• speech API
• Contacts API in desktop, related permissions situation
• tests
• resolving intermittent test failures
• High-level goal: obsolete the app store model
  • Reasoning: if we avoid that kind of dependency, the web really is the platform
  • Todo: figure out how to make that happen
  • remove divide between apps and web, especially WRT security