Closed Bug 1206207 (android-push) Opened 9 years ago Closed 6 years ago

[meta] Tracking bug for Push Notifications on Android

Categories

(Firefox for Android Graveyard :: General, defect, P5)

defect

Tracking

(firefox43 affected, relnote-firefox 49+)

RESOLVED FIXED
Tracking Status
firefox43 --- affected
relnote-firefox --- 49+

People

(Reporter: edwong, Unassigned)

References

Details

(Keywords: feature, meta)

      No description provided.
Depends on: 1201571
Blocks: 1179015
Blocks: 1201571
No longer depends on: 1201571
No longer blocks: 1179015, 1201571
Depends on: 1179015, 1201571
Blocks: 1201571
No longer depends on: 1201571
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.
Flags: needinfo?(snorp)
Flags: needinfo?(edwong)
:kar per comment #1 - could you provide a link to user stories for fennec front end work towards.
Flags: needinfo?(edwong) → needinfo?(krudnitski)
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).
Flags: needinfo?(krudnitski)
(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.
Alias: android-push
snorp: no need for you right now.
Flags: needinfo?(snorp)
Depends on: 1229835
Depends on: 1233150
Depends on: 1235431
Depends on: 1243856
No longer depends on: 1243856
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
relnote-firefox: --- → ?
nalexander, have we added any probes for this to measure success?
Flags: needinfo?(nalexander)
(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.
Flags: needinfo?(nalexander) → needinfo?(bbermes)
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
Flags: needinfo?(bbermes) → needinfo?(edwong)
(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).
Flags: needinfo?(edwong)
Depends on: 1264797
Depends on: 1278851
Depends on: 1279306
Added to the release notes using Lawrence's wording.
Used https://developer.mozilla.org/docs/Web/API/Push_API as link
Depends on: 1280446
Relnote 49+ added "Deliver asynchronous notifications via Push API"
QA Contact: ioana.chiorean
Depends on: 1308664
Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195

Needinfo :susheel if you think this bug should be re-triaged.
Priority: -- → P5
This has long since landed.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.