775963 - WebAPI for creating tray icons/menu extras

Status: RESOLVED WONTFIX

(Firefox Graveyard :: Webapp Runtime, enhancement, P2)

Description

[Marco Castelluccio [:marco]]

On the desktop, we could give apps the opportunity to run in the background and have a tray icon. This feature would be really useful for messaging applications, music players, etc.

There's a discussion here for B2G: https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.webapi/NFXLBW5A0JU

Comment 1

[Myk Melez [:myk] [@mykmelez]]

We're actually conflating two ideas here.

The B2G discussion about "background services" is about something like a service on Android <http://developer.android.com/guide/components/services.html>, a daemon on Unix <http://en.wikipedia.org/wiki/Daemon_%28computing%29>, and a service in Windows <http://en.wikipedia.org/wiki/Windows_service>: a long-running process that runs in the background, without any visible UI, and is started/stopped automatically by the system rather than the user.

Whereas a "tray icon" on Windows, and a "menu extra" on Mac, is a visible UI element for a running application that may run for a long time, and may be started/stopped by the system, but isn't necessarily so.  In other words, it's UI for an app that may or may not run as a background service.

Both background services and tray icons/menu extras do seem like they would be useful features, and they may be even more useful in combination, but it'd be better to track them in different bugs, since their implementations are different.

So let's make this bug be about an API for tray icons/menu extras, since the "background services" idea is being worked on independently and is a cross-runtime feature, whereas a tray icons/menu extras API is specific to the desktop runtime.

Comment 2

[Travis Choma]

Had some initial discussion with Marco on this one. More research to be done. But here are a few thoughts to get the ball rolling.

It seems like tray icons and menu extras main usecases are for 1) quick access to the app and 2) for communicating extra information about the app - i.e. incoming message, or syncing complete .

In terms of basic things to support:
-Defining an icon, and allowing it to be set programatically depending on the state of the app.
-On click of the icon either reveal a system menu as styled by the given platform, or a custom view as defined by the app. The menu allows developers an easy way to list quick actions like "New Tweet" in the case of Twitter's app without having to maintain an entirely new piece of chrome. However where it makes sense having the option for a custom window it allows for deeper integration, i.e. evernote defines a drop zone for dragging files to...

On the OS X side there are two interfaces into this functionality, one is NSStatusItem which is public but more limited, and the other is NSMenuExtra which is a private api. http://duhanebel.wordpress.com/2010/04/02/nsmenuextra-how-to-work-with-undocumented-apis/

One example of an abstraction over the two is in Java for what it's worth: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/examples/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet143.java

I haven't had a chance to enumerate the possibilities on the Linux side yet.

Comment 3

[Myk Melez [:myk] [@mykmelez]]

Per bug 1238079, we're going to disable the desktop web runtime and remove it from the codebase, so we won't fix these bugs in it.