Mike West | 16 Oct 15:34 2014

[Credential Management]: Tiny prototype to play around with.

BCCing public-webapps <at> , as this proposal started there[1]. It looks like it might be reasonable to charter the spec work as part of the WebAppSec WG[2], however, so I'm moving the conversation here for the time being.

Way back in August, I proposed a credential management API. After some generally positive conversation with folks at Mozilla and other vendors, I started poking at a prototype in Chrome to help us evaluate whether the API made any sense. As of some time earlier this week, there's enough in Canary to start looking at.

If you visit https://credential-manager-api-test.appspot.com/ in Canary with the '--enable-credential-manager-api' flag set, you can save credentials via `navigator.credentials.notifySignedIn()` and retrieve them via `navigator.credentials.request()`. It only supports "local" credentials, and doesn't do any of the UI song and dance that's still very much TBD, but it's a nice proof of concept.

Note: Don't do this on any profile with data you care about. The current implementation just blindly returns the first credential that matches the origin on which the API is called, without user mediation. That's probably not something you want to expose to the web in its current state. :)

I'd invite you to take a look at the strawman proposal (https://mikewest.github.io/credentialmanagement/spec/), and help me decide whether the API makes any sense. If nothing else, it'll give us something to talk about at TPAC.

Mike West <mkwst-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Google+: https://mkw.st/+, Twitter: <at> mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Brian Kardell | 9 Oct 19:53 2014

[Push] one or many

I'm really confused by what seems to me like contradictory prose... In
the interface definition it says

Note that just a single push registration is allowed per webapp.

But in multiple places it seems to suggest otherwise, for example, in
the section on uniqueness it says:

webapps that create multiple push registrations are responsible for
mapping the individual registrations to specific app functions as

Can someone clarify why those seem contradictory?  Can a webapp have 1
registration, or many?


Paul Knight | 19 Jun 22:09 2014

30-day Public Review for Advanced Message Queuing Protocol (AMQP) WebSocket Binding (WSB) Version 1.0 - ends July 19th

OASIS members and other interested stakeholders, 

The OASIS Advanced Message Queuing Protocol (AMQP) Bindings and Mappings (AMQP-BINDMAP) TC [1] members have recently approved a Committee Specification Draft (CSD) and submitted it for 30-day public review:

Advanced Message Queuing Protocol (AMQP) WebSocket Binding (WSB) Version 1.0 
Committee Specification Draft 01 / Public Review Draft 01 
10 June 2014 


The AMQP WebSocket Binding specification defines a mechanism for tunneling an AMQP connection over a WebSocket transport. It is applicable as an approach for general firewall tunneling and for Web browser messaging scenarios.

TC Description:

The purpose of the AMQP Bindings and Mappings (AMQP-BINDMAP) TC is to define bindings of AMQP 1.0 core protocol to underlying transports other than TCP, to define mappings of the AMQP 1.0 core protocol to existing well-known programming APIs, and to define representations of the AMQP 1.0 message format in existing well-known languages.

For more information, see the TC Charter and FAQ.

Public Review Period:

The public review starts 20 June 2014 at 00:00 GMT and ends 19 July 2014 at 23:59 GMT.

This is an open invitation to comment. OASIS solicits feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of its technical work.


The prose specification document and related files are available here: 

Editable source (Authoritative): 



ZIP distribution file (complete):

For your convenience, OASIS provides a complete package of the prose document and related files in a ZIP distribution file. You can download the ZIP file here:

Additional information about the specification and the OASIS Advanced Message Queuing Protocol (AMQP) Bindings and Mappings (AMQP-BINDMAP) TC can be found at the TC's public home page:

Comments may be submitted to the TC by any person through the use of the OASIS TC Comment Facility which can be used by following the instructions on the TC's "Send A Comment" page, or directly at:

Comments submitted by TC non-members for this work and for other work of this TC are publicly archived and can be viewed at:

All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members. In connection with this public review of "Advanced Message Queuing Protocol (AMQP) WebSocket Binding (WSB) Version 1.0", we call your attention to the OASIS IPR Policy [2] applicable especially [3] to the work of this Technical Committee. All members of the TC should be familiar with this document, which may create obligations regarding the disclosure and availability of a member's patent, copyright, trademark and license rights that read on an approved OASIS specification. 

OASIS invites any persons who know of any such claims to disclose these if they may be essential to the implementation of the above specification, so that notice of them may be posted to the notice page for this TC's work.

========== Additional references:

[1] OASIS Advanced Message Queuing Protocol (AMQP) Bindings and Mappings (AMQP-BINDMAP) TC

RF on RAND Mode

Paul Knight  - Tel: +1 781-861-1013
OASIS - Advancing open standards for the information society
Document Process Analyst

Arthur Barstow | 29 May 00:23 2014

CfC: publish Candidate Recommendation of DOM Parsing and Serialization; deadline June 4

[ Bcc public-webapps; please Reply-to: www-dom]

Two bugs were raised against the May 1 LCWD of DOM Parsing and 
Serialization [LC]. Travis created a tracking document for these Bugs 
[Track] and considers the two patches ([P1] and [P2]) that address the 
comments as non-substantive. As such, he proposes this spec be published 
as a Candidate Recommendation (using the following ED as the basis), and 
this is a Call for Consensus (CfC) to do so:


This CfC satisfies: a) the group's requirement to "record the group's 
decision to request advancement" to CR; and b) "General Requirements for 
Advancement on the Recommendation Track" as defined in [Proc2005].

Travis estimates it will be several months before the [TestSuite] is 
complete and there are at least two implementations that pass each test 
case. Given this, I propose the following CR "exit criteria":

This specification will not advance to Proposed Recommendation before 
the spec's <a href="">test suite</a> is completed and two or more 
independent implementations pass each test, although no single 
implementation must pass each test. We expect to meet this criteria no 
sooner than  <at> PubDate+4Months. The group will also create an <a 
href="">Implementation Report</a>.

If anyone has feedback regarding features that should be marked "at 
risk", please speak up during this CfC.

Positive response to this CfC is preferred and encouraged and silence 
will be considered as agreeing with the proposal. The deadline for 
comments is June 4 and all comments should be sent to public-webapps  <at>  

-Thanks, ArtB

[LC] <http://www.w3.org/TR/2014/WD-DOM-Parsing-20140501/>
[Track] <https://dvcs.w3.org/hg/innerhtml/raw-file/tip/LC2_comments.html>
[P1] <https://dvcs.w3.org/hg/innerhtml/rev/dc7083c47f77>
[P2] <https://dvcs.w3.org/hg/innerhtml/rev/8dbd8dbdefdc>
[TestSuite] <http://w3c-test.org/domparsing/>

Arthur Barstow | 28 May 16:42 2014

PSA: publishing FPWD of D3E Keyboard {key,code} Values specs and WD of UI Events

[ Bcc: public-webapps; please Reply-to: www-dom ]

As previously discussed, Gary and Travis have moved the D3E event key 
and codes from the D3E and UI Events specs to the following new specs:

* DOM Level 3 KeyboardEvent key Values 

* DOM Level 3 KeyboardEvent code Values 

They are working towards publishing FPWDs of these specs next week as 
well as a new WD of the (now much smaller) UI Events spec:


If anyone has any comments or concerns about this plan, please speak up 
by June 2 at the latest.

-Thanks, AB

Simon Pieters | 12 May 11:24 2014

Re: Custom Elements: 'data-' attributes

On Mon, 12 May 2014 11:00:20 +0200, Anne van Kesteren

> On Fri, May 9, 2014 at 12:56 PM, Ryosuke Niwa <rniwa@...> wrote:
>> On the other hand, if the same element had exposed contentEditable  
>> property, then UA's native contentEditable property would simply be  
>> overridden since it would appear higher up in the prototype chain.   
>> It's true that this custom element's contentEditable would have  
>> completely different semantics from that on other elements but that  
>> wouldn't break websites that use this custom element as long as authors  
>> are only accessing contentEditable property on instances of the custom  
>> element for semantics C.
> I forgot the exact details, but we had some amount of trouble when we
> introduced min and max attributes due to sites using expandos with the
> same names.
> I think we need something better than encouraging certain conventions
> if we want this to work.

Bare names in event handler content attributes are troublesome.

For instance, sites doing:

<button onclick="action()">

made us have to rename <button action> to <button formaction> (the new  
.action reflecting action="" was closer in the scope chain than the  
intended function).

Global attributes have the same issue.

So when we research if it's safe to add a new global attribute, it's not  
enough to measure how often such an attribute is used in the wild. We need  
to research bare names in event handlers also.


Simon Pieters
Opera Software

Wilson Page | 6 May 20:19 2014

Custom Elements: 'data-' attributes

I'm unsure whether or not it is safe to use custom attributes without the 'data-', I've heard mixed opinions. How do we know that chosen attributes won't someday be global attributes?
Arthur Barstow | 1 May 17:30 2014

RfC: LCWD of DOM Parsing and Serialization; deadline May 22

[ Bcc: public-webapps and public-html-admin; please Reply-to: www-dom ]

WebApps requests comments on the May 1 Last Call Working Draft of "DOM 
Parsing and Serialization (DOMParser, XMLSerializer, innerHTML, and 
similar APIs)":


If you have any comments, please send them to [www-dom] by May 22 at the 
latest. WebApps also welcomes data about "silent reviews", f.ex. "I 
reviewed section N.N and have no comments".

HTMLWG - WebApps especially welcomes feedback from you.

-Thanks, AB

[www-dom] <http://lists.w3.org/Archives/Public/www-dom/>

Marcos Caceres | 21 Feb 19:33 2014

[Manifest] Study on installable web apps

(bcc'ing SysApps and WebApps)

Over the last week, the WebMob IG did a somewhat large study of installable web apps based on iOS.  

In the hope that the findings help with standardization of the manifest, I'd like to share the findings and
some recommendations with the WGs. 

If you would like to read the whole study, including methods, limitations, and data, see [1]. You can also
file bugs there. 

Despite the issues outlined below, we must acknowledge that Apple has done exceptional work in pioneering
the concept of "installable web apps" (and continue to make this stuff better and better with each release
of iOS). This is not intended to be a criticism of iOS - just a reflection of how the technology is being used
in the wild. 

## Key findings
The number of sites claiming to run as standalone is insignificant: of all sites we had access to, they
represent 1.4% of the dataset (i.e., 1097 out of 78,155 claim to be "`apple-mobile-web-app-capable`").
So, despite this capability being available since 2009, and irrespective of iOS being the dominant
mobile platform, few developers bother to create standalone web apps.

Despite these 1097 sites claiming they can be used as standalone, what we found was that the majority of web
apps (90%, or 324 out of 360) **can not be used as standalone**. Only a tiny fraction (10%, or 36 out of 360)
are able to run as standalone - and 28% of those had significant limitations (described below). There is,
in fact, a greater percentage (12%) of desktop sites masquerading as installable web apps than there are
actual standalone applications. 

Another significant problem is that 85% (307 out of 360) of apps rely on a user's ability to follow
hyperlinks. iOS standalone apps don't support following hyperlinks: unless a developer intervenes via
JavaScript, the default action is to open links in Safari. The data effectively busts the myth of "single
page apps": we found that almost no developers build single page apps in practice for this class of

Of those 36 apps that were true standalone web apps (i.e., has an icon, is usable on a mobile device, can be
navigated), 10 (28%) of those had issues where they either left the user stranded without being able to "go
back" - or worst, suddenly navigated to the desktop version of the site. The only option for a user is to drop
back to the home screen and open the application again. This causes iOS to load the page that was originally
bookmarked. This itself has problems, in that if the user leaves a web app, its state is effectively lost -
meaning the application can lose data. 

In other cases, a web application mostly worked but then it was not possible to perform some critical task
within the application (e.g., a purchase). In such cases, the application returned the user back into
Safari. Others, like [nest.com](http://nest.com), make a best effort at working as standalone, but
throw the user back to the default web browser at random points.  

On the up-side, the majority of web apps (76%) where designed to work on a mobile phone, even if only 13% of
those could actually be navigated.

Icon usage, overall, was also fairly healthy - 56% of the web apps we tested included an icon. However, we
discovered that at least some web apps included dummy icons from pre-purchased templates - meaning more
than one web app included an icon that had nothing to do with the application itself and had the same icon as
another site.

Oddly, many web apps (5%, or 19) incorrectly claim that they can run as standalone - but contain a markup
error in their HTML that prevents the application from actually doing so! Of those, 12 out of 19 (63%) even
go as far as to include an icon. These icons are still useful when the app is added to the home screen or
bookmarked - just the web apps won't run as standalone.

For more details, see the "Other observations" and the "All questions" section in [1].

## Recommendations to implementers/W3C
>From our findings, this is what we would recommend implementers and the W3C consider when standardizing
this technology. 

* It has to be possible for users to follow hyperlinks in standalone applications. Even though iOS doesn't
support this functionality, the data clearly shows developers rely on this core capability of the Web.

* It needs to be possible to open some links in the system default browser: it doesn't make sense to open some
links, like ads, within the application.

* It has to be possible to open a browser window within the application: this is to allow OAuth style
authentication (which are blocked from working in iframes).   

* It needs to be possible for the user to navigate "back". A significant number of a apps, unfortunately,
leave users stranded without a way to "go back" in their browsing history. This is sometimes outside the
developers control (e.g., an authentication screen at a different domain doesn't support going back).
Having some ability to always go back seems critical to make this class of web application usable by the
general public.  

* Do not expect, or encourage, developers to create single page applications. Some will, but they will
likely do it wrong. Most everyone won't: it's too hard, unnecessary, and evidently error prone.

* Don't expect applications will have good metadata or icons. 

* Automatically generated metadata and template engines will likely be an issue. A lot of sites don't seem
to test (or might not even know) that their websites supports running as standalone. 

* To avoid the issue of UA-specific pop-up banners, a standard way to "install" an application is needed:
either through and API and/or some declarative means.

* It needs to be possible to be able to jump between web apps and native apps without requiring the developers
to constantly save state. That is, leaving a standalone web application should work the same as jumping
from one browser tab to another in a desktop browser. 




Marcos Caceres

John Mellor | 19 Dec 18:02 2013

Background sync & push messaging: declarative vs imperative

[cross-posted to public-webapps and public-sysapps]

A couple of us from Chrome have taken a holistic look at how we could add standardized APIs for web apps to execute/sync in the background.

This is an important capability, yet can be safely granted to low-privilege web apps, as long as battery consumption and metered data usage are (very) carefully limited.

This is not a spec proposal - instead I’m looking for feedback on the high-level choice between an imperative or declarative set of APIs.


1. Sync when next online

- Need to send emails & document edits written offline as soon as the device goes back online (even if app is not open), and get back sending status, or for documents the result of merging the user's diff with any changes made by other users.

e.g. document editing / email client / instant messaging / play-by-mail games

2. Background sync

- Need to periodically fetch new content in the background, so user will have fresh content if they open the app offline.

- Content often depends on device location (hence requires polling).

e.g. news / weather / maps / social stream

3. Large background transfers

- Need to upload/download large files. App won't remain in the foreground for long enough, so this must happen in the background; and even in the background, the app is unlikely to be allowed to stay open long enough (e.g. iOS 7 limits the execution time of Background Fetch to 30 seconds), so there needs to be a way of handing over large transfers to the browser/OS to perform efficiently without the app having to keep running.

- Ideally such transfers would auto-resume after device reboots.

e.g. file syncing / movies / video camera

4. Push notifications

- Need instant push notification of messages received by the server, or as soon as the device comes online if it was offline (even if app is not open).

e.g. email client / instant messaging / play-by-mail games

5. Push to sync (tickle)

- Sometimes a push needs to trigger a sync, for example to fetch email attachments.

e.g. file & document syncing / email client / play-by-mail games

6. Delayed local notifications

- Need to show notifications at some time in the future.

- Various possible interactions with timezone changes and daylight savings time.

e.g. egg timer / alarm clock / calendar

7. Delayed remote notifications

- Consider a calendar app: it must reliably show notifications for remotely-added events, even if the app hasn’t been opened since the event was added. Hence there must be some mechanism for a push message from the server to cause a local notification to be set at some time in the future.

e.g. calendar / cloud synced alarm clock

Solving all of these requires a variety of different APIs. But it's important that they fit together well, and it turns out that the API design choices are closely interrelated.

There are two broad approaches to providing such capabilities on the web:


One approach is to allow JavaScript to be run on demand in the background. The prime candidate for this is to extend ServiceWorkers to be a generic mechanism for receiving events in the background (without a page having to be open).

1. Sync when next online

To address use case #1, add an API that requests your ServiceWorker to get woken up once in the background, as soon as possible after the device next goes online. This could be an extension of the Task Scheduler API. This API should probably only be available when running in the foreground.


   requireOnline: true

}, myData);

2. Background sync

Similarly, to address use case #2, let web apps request their ServiceWorker to be periodically run in the background, at an interval of the UA’s choice (using aggressive heuristics to choose the most battery/data-efficient moment to run it); though we could allow the developer to specify a minimum interval (i.e. if content updates daily, you could specify that there’s no point syncing more often).


   minInterval: "2h"  // UA will pick a >= interval

}, myData);

We’d probably strictly limit the execution time of the ServiceWorker to conserve battery (by comparison, in native apps iOS 7 limits the execution time of Background Fetch to 30 seconds).

3. Large background transfers

Although we’d be limiting background execution time of the ServiceWorker, we can compensate by making it possible to initiate long-running up/downloads, managed by the browser/OS.

This could be done by letting you mark async XMLHttpRequests as "persistent", somewhat like the Beacon API, except that the browser would periodically retry requests if the device was offline, and make the results available to the page or ServiceWorker next time the web app is launched.

Alternatively we could reuse ServiceWorker’s scriptable Cache objects. You’d get syntax something like this:

caches.set("movie-cache", new Cache(




This would cause the UA to download these large files in the background. Once all the downloads in the cache are finished, they would show up in caches.get("movie-cache").

4. Push notifications & 5. Push to sync (tickle)

To address use cases #4 and #5, implement something like the Push API, allowing servers to remotely wake up a ServiceWorker. The ServiceWorker can then sync, show a notification, etc. (For battery life reasons, silent push messages probably need to be throttled, in which case we could consider adding a never-throttled variant for messages that show a user-visible notification).

PUT /push/send/device-c0fa407591 HTTP/1.1

Host: browser-push-server.com


6. Delayed local notifications

To address use case #6, extend the Notifications API so notifications can exist independently of the lifetime of a web page, and when activated will wake up the ServiceWorker or web page and fire an event on them.

There also needs to be a way to fire a notification after a precise time delay; the natural way to do this would be to also allow exact scheduling of time sensitive tasks using the Task Scheduler API, but for battery reasons we shouldn’t give web apps carte blanche here; instead to prevent abuse we might want to only allow exact scheduling if you also show a user-visible notification. So we could either silently throttle precisely scheduled tasks if it turns out they’re not showing notifications, or we could not implement exact scheduling in Task Scheduler at all, and instead extend Notifications to have an optional time delay.

new Notification("Meeting about to begin", {

   utcTime: 1386011460303,

   body: "Room 101",

   launchUrl:  "https://my-app.com/?from=notification"


7. Delayed remote notifications

By combining the APIs from the previous two sections, you can have a push message handler that schedules a delayed notification, satisfying use case #7.


Alternatively, it would be possible to solve almost all these use cases without having to run JavaScript in the background, with a combination of declarative APIs. This seems to be a new idea, so it warrants more detailed explanation.

A key premise of this approach, is that it’s always ok to wake up the device/app in order to display a user-visible notification, since these provide value to the user (or if they don’t, the user can deal with it by revoking the permissions of the web app). But other than that, it’s best to limit battery/bandwidth/RAM consumption in the background.

*These are just pseudo-APIs to demonstrate possible capabilities and not actual proposals.*

1. Sync when next online & 3. Large background transfers

For use cases #1 and #3, uploads and downloads need to happen in the background, and in a declarative world these would need to be fully managed by the browser. As in the imperative approach to use case #3, we could reuse ServiceWorker’s scriptable Cache objects for background downloads, either from a ServiceWorker, or by exposing them to ordinary web pages:

caches.set("movie-cache", new Cache(




This would cause the UA to download these large files in the background. Once all the downloads in the cache are finished, they would show up in caches.get("movie-cache").

Similarly background uploads are sometimes necessary. For use case #1 (e.g. email), it is important that the background upload happen as soon as possible once the device goes back online; for use case #3 (e.g. video sharing), the background uploads need to support uploading large files, however timeliness is less important, and it might be best for the upload to only happen over WiFi. It might still be possible for the two to use the same syntax; for example we could allow adding a Request object to a Cache instead of just URLs:

caches.set("outbox", new Cache(new Request({

   method: "POST",

   url: "http://my-app.com/send-mail",

   body: my_mime_multipart_message

}), ...));

The UA would perform these requests in the background, and store the response in the cache object. As for urgency, perhaps there could be some "urgent_request_by_user" flag that the web developer can set to indicate that the user explicitly requested this and intends it to be sent over cellular data.

2. Background sync

The mechanism above is powerful, but sometimes instead of a one-shot up/download you need to sync data that regularly updates.

Push can be great for that; but sometimes you have to poll, for example weather/map apps syncing forecasts/tiles based on your current location. And sometimes (though perhaps rarely) even when you can push it’s more efficient to poll smartly - for example if my social network feed has new posts several times a minute, I really don’t want it waking up my phone radio every few minutes while I’m asleep (especially if I forgot to plug it into a charger).

We could extend the caches mechanism above with the ability for the UA to periodically check -- in the background -- for updates to the files in the cache (using standard HTTP caching logic). The UA could optionally include the user’s geolocation in a header when doing so.

caches.set("sync-cache", new Cache(url1, url2, ...));

caches.requestBackgroundSyncing("sync-cache", {

   geolocation: true


The client would indicate with cookies or somesuch any user preferences about what should be synced. The server could update the cookies to indicate how much it has synced, so during the next sync it knows what to do.

However this is still quite limiting, as it requires the client to know in advance the URLs of the files the server will want it to download. It would probably lead to hacks where clients request that a bunch of meaningless foo1, foo2, foo3 urls get synced, and the actual content of those urls gets rotated server-side. A more flexible approach would add indirection, and let the server provide a barebones "manifest" file, that would just be a newline-separated list of URLs to sync.

caches.set("sync-cache", new CacheManifest("/sync-manifest"));

caches.requestBackgroundSyncing("sync-cache", {

   geolocation: true


The UA would periodically check for updates to the manifest file, fetch any new URLs, update existing ones, and delete cache entries for any URLs removed from the manifest. Updates would presumably be atomic (sync all files in the manifest before updating the cache exposed to the page). I’ve glossed over various details, such as what constitutes an update to the manifest file, but it should be possible to define something reasonable, learning from the lessons of AppCache.

As with the imperative approach, the UA would use various heuristics to determine when is a good time to sync each app, such as batching, screen on, wifi available, charging, or even what times of day each web app is typically used.

4. Push notifications

For use case #4, there needs to be a standardized way for an app’s server to instantly push user-visible notifications to the device (with automatic retry if the device is offline). Interacting with the notification would launch the app, at the given URL.

POST /push/send/device-c0fa407591 HTTP/1.1

Host: browser-push-server.com

Content-Type: application/json


   "title": "Message from Ben",

   "body":  "This should arrive instantly :)",

   "sound": "https://my-app.com/you-got-mail.mp3",

   "launchUrl":   "https://my-app.com/?from=notification"


5. Push to sync (tickle)

In the push notification example above, the notification didn’t contain any data other than the notification text, and the URL to launch when the notification was clicked. It would be reasonable to add a "data" member to the JSON, which would somehow be passed to the web page when the notification is clicked.

However most push messaging servers have strict size limits on the payload (e.g. 4096 bytes). There are many cases, where an app needs to send more than this, for example an email client that needs to download the attachments that accompany an email, so that if the user clicks the notification whilst offline, they will be able to view the attachments.

To handle this case, we can allow a silent push message that kicks off an immediate background sync of one or more of the named caches from "2. Background sync" above:

POST /push/send/device-c0fa407591 HTTP/1.1

Host: browser-push-server.com

Content-Type: application/json


   "updateCaches": ["sync-cache", "attachments-cache"]


6. Delayed local notifications

For use case #6, there needs to be a way to locally schedule notifications with a time delay (since the device might be offline the whole time, you can’t rely on push notifications for this). We could extend the Notifications API as follows:

new Notification("Meeting about to begin", {

   utcTime: 1386011460303,

   body: "Room 101",

   launchUrl:  "https://my-app.com/?from=notification"


The notification would be delayed until the given moment. A URL is provided to launch the app in response to the user clicking on the notification, if the app isn’t already running; usually, this URL would be available offline due to AppCache or a ServiceWorker. An API like Notification.get() would let you read and cancel pending notifications.

7. Delayed remote notifications

A subtle variant of notifications is use case #7. If you add a same day event to your cloud calendar with a reminder 10 minutes before the event, then the device goes online for a while but the calendar app does not get launched by the user, and the device goes back offline for the hours leading up to the event, the calendar app needs to be able to fire that notification 10 minutes before the event, despite (in this declarative model) having been executed neither at the time the push notification arrived, nor at any time since then.

Since it doesn’t get executed, such an app can’t locally schedule a delayed notification, so instead the push notification API introduced for use case #4 could be extended so you can specify a time delay before the notification fires (as with delayed local notifications).

POST /push/send/device-c0fa407591 HTTP/1.1

Host: browser-push-server.com

Content-Type: application/json


   "utcTime": 1386011460303,

   "title":   "Meeting about to begin",

   "body":    "Room 101",

   "launchUrl":     "https://my-app.com/?from=notification"


We’d need to also support push messages that cancel earlier delayed push notifications (e.g. if the event later gets removed from your cloud calendar). And the same API that lets you inspect local delayed notifications could also read/cancel pushed delayed notifications.


The imperative approach (A) seems a cleaner set of APIs, from an extensible web point of view.

However whenever a ServiceWorker (or equivalent) runs in the background, it requires a full JS interpreter, and all the associated browser machinery to support APIs like Geolocation, which together consumes a significant amount of RAM. This can be a problem on mobile; for example on Windows Phone, background agents are restricted to 11 MB of RAM on devices with less than 1GB, otherwise 20 MB, and are terminated if they exceed this limit. This is presumably in order to ensure that the foreground app (and other important processes) remain responsive (and don’t get evicted). The limits on Android and iOS are vaguer and device-dependent, but increased background RAM usage could potentially be a deal-killer for the imperative approach.

(The UA can tightly control battery and data usage in both the imperative and declarative approaches described above, which is why I’m not focusing on those here).

We’re currently thinking of prototyping the imperative approach. But it seems that the 2 main capabilities introduced incrementally in section B (declarative push message actions, and the caches mechanisms) could provide a viable plan B if the imperative approach turns out to use too much RAM.

*Please don’t bikeshed the syntaxes yet*; at this stage the main open questions are:

  1. Is this a reasonable vision for the set of imperative capabilities?

  2. Would such declarative capabilities be sufficient to address all important use cases?

  3. How easy would web developers find developing against such declarative APIs, compared to the imperative approach? The server would play a slightly greater role in driving the sync logic; but that may not be so terrible.

  4. How much RAM would such a declarative approach ultimately save? Is it worth it?


Arthur Barstow | 19 Dec 15:54 2013

[testing] Common way to "manage" test bugs?

[ Bcc: public-webapps-testsuite ]

Hi All,

I think it would be helpful if WebApps had a common way to "manage" test 
case bugs,  in particular:

1. A common way to report a test bug

2. An easy way to determine if a specific test suite has any open bugs. 
(For example, if someone goes to the websockets test suite on WPT, it 
should be easy to determine if any of the test cases have open bugs.)

Currently, tests bugs are reported in a few different ways:

* Bugzilla - WebApps has a single Testing component in Bugzilla for all 
of the specs and it has been used to report a few test case bugs [Bugs]. 
Using Bugzilla addresses #1, however, a single component makes #2 a bit 
tricky although that could be addressed by prefixing titles with the 
spec name (e.g. [workers] ...).

* GitHub PRs - some bugs are noted in comments to a PR (and thus making 
#2 a bit difficult).

* GitHub Issues - some bugs are reported as a Github Issue but GH's 
Issue granularity is for all of [WPT] and not per spec (thus making #2 a 
bit tricky, although title prefixing could help).

* The WPT root [WPT] is silent on how to file bugs (although some 
sub-resource could address that) and that could be appropriate if we 
expect every test suite to be able to customize its bug reporting policy.

If we agree Bugzilla should be used to report all test case bugs: 1) 
should we have an agreed way for a test suite in WPT to point to 
Bugzilla (although Bugzilla has bug reports for websockets and workers 
tests, that link is missing from the test suites); 2) should we continue 
to lump all of the tests in a single component or create per test suite 
components (e.g. tests-workers, workers-tests, ...).

Comments, proposals, etc. are welcome.

-Thanks, ArtB

[WPT] <https://github.com/w3c/web-platform-tests>