[whatwg] Notifications UI for Persistent Workers

[John Gregg]

Hi WHATWG,

There have been discussions in the past about building notifications
("toasts") as a way for workers, especially persistent workers, to have a
form of UI.  It's not spec'd in HTML5 at the moment, but I'm currently
working on an implementation in Chromium and wanted to get broader feedback
on the design we're working from.  Here's our design doc.  Thoughts?

Thanks,
  -John


*Notifications for Persistent Workers*

*Background*

Persistent workers run scripts in the background, potentially in the absence
of open tabs connected to that worker script.  This document describes a way
for these scripts to interact with the user through notifications: "toasts"
which appear on the user's desktop, outside of any tab.

QUESTION: Dedicated and shared workers, though able to interact with the
user through open tabs, also have compelling use cases where desktop UI
serves better than in-tab UI (e.g., Calendar alerts and "New Email"
notifications). Should this be extended to all such contexts?  There are
implementation benefits to limiting notifications to shared workers
(avoiding duplication of notifications, etc.), but this may present a burden
to developers who wish to incorporate notifications in a webapp with minimal
effort.  This document will limit itself to the application in shared &
persistent workers.

*Capabilities*

User-agents may implement desktop notifications in different ways.  The
strongest form provides full HTML display, where a URL is loaded and
presented in a small desktop balloon. In some environments structured
notifications (icon, title, text) are more canonical, e.g., Ubuntu's
libnotify and Growl.

In addition, HTML5 browsers which do not have a "desktop" in the traditional
sense, such as those on a mobile device, may wish to implement notifications
using text-only, text-plus-icon, or other structured notifications.  For
example, Palm OS offers structured notifications on mobile devices, but not
full HTML.  For greatest compatibility, the spec should provide alternatives
for these different environments.

When HTML notifications are used, they should act like normal browser
windows, including stylesheets and script functionality, with the exception
that links causing a location change should always open in a new tab.

*Proposed Specification*

SharedWorkerGlobalScope {
 ...
 readonly attribute Notifications notifications;
};

interface Notifications {
 NotificationObject createHTMLNotification(URL url);
 NotificationObject createNotification(StructuredNotification n);

 /* see "Permissions" below */
 readonly attribute boolean trusted;
 void requestTrust();
};

In the Notifications interface, user agents may leave undefined
createHTMLNotification() if they do not support HTML notifications.

[nointerface] interface StructuredNotification {
 DOMString title;
 DOMString /* URL */ icon;
 DOMString body;
 /* ... perhaps other fields can be optional ... */
};

interface NotificationObject {
 boolean show();  /* show (queue for display) the notification. throws on
repeat calls. */
 boolean cancel();  /* close the notification if displayed; cancel it if not
yet */
 attribute boolean sticky;

 attribute EventListener ondisplay;
 attribute EventListener onerror;
 attribute EventListener onclose;
 /* ... perhaps other events ... */
}

Applications' worker scripts can use standard normal capabilities-checking
techniques to choose which function to call, HTML or structured.

Notifications may be 'sticky', meaning the toast is shown until dismissed by
the user, but by default they are not sticky, and will be removed after a
period of time which is controlled by the user-agent and underlying desktop
based on its own display properties.  A worker script may attempt to change
the stickiness before showing, although this change may not be successful if
not allowed by the environment (e.g., Ubuntu's libnotify does not support
sticky notifications at all).

Before showing a notification, the worker script can register for event
callbacks defined above. All callbacks are asynchronous.

   - "ondisplay": when the notification is actually shown to the user.  If
   it is queued for UI space limitations, this may be deferred.  This event
   allows scripts to control notification display intervals more precisely if
   desired.
   - "onerror": if the notification cannot be shown for some reason, for
   example if the URL provided generates an error response.
   - "onclose": when the notification is closed by the user or by the
   notification provider.  Non-sticky notifications may close themselves
   automatically, thus the 'onclose' event should include an "explicit"
   attribute which indicates if the user took an action to dismiss the
   notification.


*Example*

if (notifications) {
  var n;
  if (typeof(notifications.createHTMLNotification) != "undefined") {
    n =
notifications.createHTMLNotification("/ui/event_starting?id=31415&title=Team+Meeting&location=Room+1200&time=1700");
  } else {
    n = notifications.createNotification({icon: "/images/event.png", title:
"Team Meeting", body : "Room 1200, 5:00pm"});
  }
  n.sticky = true;
  n.onclose = function(e) { if (e.explicit) { /* ping server, mark event
acknowledged */ } };
  n.show();
}

*Permissions*

As with any UI elements, the potential exists to annoy users by misuse of
the feature. If notifications are available to non-persistent workers or
pages, it can be mitigated by separating applications into trust zones
defined by the user-agent, where trust is granted by the user. Since
persistent workers require installation permission, user agents might
combine notification permission with install permission.

Desktop placement is limited to trusted origins; untrusted origins'
notifications can be shown within a browser tab rather than on the desktop
(like a non-modal alert dialog, with the queueing benefits of the
notifications system).

Scripts can determine if they are trusted by checking the
notifications.trusted attribute and can use notifications.requestTrust() to
request permission from the user to become trusted, through an info-bar or
other conventional permissions flow at the discretion of the user agent.

*Security/Phishing*

When the notification bubbles are shown outside the browser window, and
contain fully interactive HTML, there is a potential concern that a
compromised or misbehaving worker script might create a phishing opportunity
by requesting user input in a notification bubble.

It is recommended that HTML notification bubbles always contain a
recognizable browser frame, which displays the origin source of the bubble
and identifies HTTPS and other security elements in a standard way.
*
Offline Use/Application Cache*

Some notifications have a strong offline use case, such as calendar
reminders.  To make the necessary icon images and HTML notification
templates available offline, HTML notification windows should have access to
the same application cache as the worker which created them, if present, or
follow the normal application cache selection algorithm for new windows.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090331/75b7d199/attachment-0001.htm>