edwong: I've broken down the low-level Fennec GCM integration into smaller work items, which I will push forward in the next weeks. There are, of course, many other parts to "Push Notifications". Presumably, there's some consumer of the GCM bridge tracked by Bug 1179015 (for example, the mooted Device Manager, or some other mechanism for triggering Syncs). I don't know what the concrete use case for the bridge is. edwong, please fill in. Presumably, there's some integration with Service Workers and "Web Push", but I don't know what shape that takes. In addition, I expect there to be Android-specific UX needed to present "Web Push" notifications and a permissions API, but again, I don't know what shape that takes. snorp, please connect to whatever platform tickets you are aware of.

:kar per comment #1 - could you provide a link to user stories for fennec front end work towards.

Edwin - I'll add the Aha! feature cards where we're tracking the use cases we want covered. The first primary use case is 'Send tab to', a proactive action of sending a tab in near real-time with a corresponding notification alerting the user): https://mozilla.aha.io/features/FENN-347 Supporting this will likely then support other use cases, as well as unravel the complexities on mobile (ie notifications in the foreground vs background, how users can interact with notifications, etc).

(In reply to Karen Rudnitski [:kar] from comment #3) > Edwin - I'll add the Aha! feature cards where we're tracking the use cases > we want covered. > > The first primary use case is 'Send tab to', a proactive action of sending a > tab in near real-time with a corresponding notification alerting the user): > https://mozilla.aha.io/features/FENN-347 Hi kar, I'm not sure you're on the 'push' list, but I posted a different focus and work breakdown there. I will surface it to mobile-firefox-dev, with a more Android-technical slant. In short, I'm focusing on the enabling the DOM push API when Gecko is actively running. Use cases like an enhanced Send Tab require other work: mostly co-ordination with the Identity and Services team and backend support. > Supporting this will likely then support other use cases, as well as unravel > the complexities on mobile (ie notifications in the foreground vs > background, how users can interact with notifications, etc). Supporting DOM push achieves this. Enhanced Send Tab mostly does not.

snorp: no need for you right now.

Release Note Request (optional, but appreciated) Note: Fennec specific. [Why is this notable]: "The Push API gives web applications the ability to receive messages pushed to them from a server, whether or not the web app is in the foreground, or even currently loaded, on a user agent. This lets developers deliver asynchronous notifications and updates to users that opt in, resulting in better engagement with timely new content." [Suggested wording]: HTML5: Deliver asynchronous notifications via Push API [Links (documentation, blog post, etc)]: Link to standard: https://w3c.github.io/push-api/ Platform coverage: Firefox for Android. This is already shipping in Firefox Desktop: the Firefox Desktop intent to implement message is at [1] and the intent to ship message is at [2]. Estimated or target release: Firefox for Android 47 is desired. 48 seems most likely. Preference behind which this will be implemented: this is both behind a build flag (due to Android-specific permission changes, etc) and behind dom.push.enabled. DevTools bug: this should be covered by the Desktop devtools ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=1214248. [1] https://lists.mozilla.org/pipermail/dev-platform/2014-July/005828.html [2] https://groups.google.com/d/msg/mozilla.dev.platform/vU4NsuKhTOY/wc2PviRUBAAJ

nalexander, have we added any probes for this to measure success?

(In reply to Barbara Bermes [:barbara] from comment #7) > nalexander, have we added any probes for this to measure success? For the Android side, no. For the WebPush API (JavaScript) side, we have telemetry histograms: https://dxr.mozilla.org/mozilla-central/search?tree=mozilla-central&q=path%3APushService.jsm%20telemetry&redirect=true, and I do see a small number of users actually displaying some push notifications: http://mzl.la/1pHcLRD. So this means that the feature is working for some users. The work I've done is really about laying the technical foundation for WebPush on Android. The Push team has a server-side dashboard and is working with targeted organizations to track whether the WebPush API is used and successful in general, but this is somewhat independent of what we've done for Firefox for Android. (The focus is very much on the Desktop market.) I think it makes sense to measure the success of using Push for things that Fennec itself wants to do, more than for the WebPush platform feature. For example, we might track how Push changes our Sync cadence, or ... perhaps you want to know specific things? Hope that helps.

thanks Nick, can't the Push team determine where the notification came from and what happened to it, i.e. since it's the platform, can't we use their telemetry to filter out mobile? NI Edwin to confirm please

(In reply to Barbara Bermes [:barbara] from comment #9) > thanks Nick, can't the Push team determine where the notification came from > and what happened to it, i.e. since it's the platform, can't we use their > telemetry to filter out mobile? > > NI Edwin to confirm please Barbara -- I talked to Ben Bangert about the Push metrics story today. Medium story short, they expect to be able to provide some metrics in the Q2 timeframe: # of Fennec user agents registered; descriptive statistics (mean, maximum) for # of sites per Fennec client; some information about # of push messages received. However, it's not yet possible to get any of that information from the Push metrics operation :(

The service can provide basic message throughput, num clients, messages per client, but mostly high level. A question we may have is: How do we know if users like Push on Fennec? * the percentage of sites blocked/allowed. * percentage of sites blocked after allowed Do we need to make it easier to block a site vs global blocking all notifications on Fennec (current method).

Added to the release notes using Lawrence's wording. Used https://developer.mozilla.org/docs/Web/API/Push_API as link

Relnote 49+ added "Deliver asynchronous notifications via Push API"

Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195 Needinfo :susheel if you think this bug should be re-triaged.

This has long since landed.