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)

The following came from a discussion with some Gecko and Gaia developers in May 2014

• DataStore in workers (rewrite in C++: bug 990554)
• child process support for FileHandle
  • FileSystem proposal is a potential future standard that can be used here
  • ex. stream into IDB, hand off fully-formed blob from IDB to download manager
    • baku says magical Blob feature Jonas wants will make this easy
• apps knowing how much memory they're using (probably a debug-only feature)
• audiochannelmanager (maybe?) feature to allow video/audio recording to be muted when a phone call or alarm happens
  • setVisible is used as a workaround here right now
  • make oom priority controllable by system app (on mozapp mozbrowsers)
• notification of interruption by events like phone call or pressing home button or alarm
  • needs UX consideration around visibility of notifications, etc.
  • having an API for an app to save its state can help here (notably in OOM situations) or perhaps some state on the visibility change event indicating why that change happened
• Passing CSS transform dimensions as typed arrays or making the current JIT faster in parsing values out of strings
• Calendar API for writing a privileged calendar app
  • mozCalendar?
  • some primitives like storage (can DataStore work with its onchange notifications?)
  • sync
    • what features do we need for some sort of local store to easily be able to sync?
  • seems like writing libraries that we can provide to apps is the best solution here
• make DataStore available to privileged apps
• media player API
  • e.g. rdio on the lock screen
  • Google has put forward an idea here about sending media key events
  • alternative is a widget
    • but then each player (e.g. rdio *and* songza *and* spotify) has to write their own custom widget
  • communication: IAC (Inter-App Communication API)?
• A standardized share Web Activity
  • see https://etherpad.mozilla.org/activities
• Figuring out what we should do for apps that want to run when the device is locked (context: activities opened from lockscreen widgets, etc.)
  • deal with exposing permissions when running in locked more (we can't prompt because prompts will go under the lockscreen.)
• attention screen (not sure what was meant here)
• localization
  • We should look into what fast path localization support we could add to our parser/dom code. This will be a significant project given how long we've fought with figuring out the right approach here.