Web Push could be a very powerful feature if exposed to GeckoView consumers. GCM is kind of a PITA in comparison (IMHO), and Android's WebView does not support it AFAIK. I am not sure what it would really look like, but it would probably provide a way for the Service Worker to communicate with an Android service.
Summary: Figure out Web Push support with GeckoView → [geckoview] Figure out Web Push support
Component: Embedding: APIs → GeckoView
Product: Core → Firefox for Android
I'll note that using anything other than native message support could cause the OS to trigger battery use warnings. That's one of the bigger reasons that we picked using GCM / APNs as a "bridge" system. There are a few other options, of course, but they come with conditions. 1) Instead of keeping a constant connection open, poll the server to see if any messages are outstanding. Cons: potentially high delay for message delivery compared with "native" implementations. 2) Use the bridge as a "poke" service. Send a "data-free" poke over the bridge to wake the UA to fetch messages using websocket method. Cons: Kinda wasteful, still requires costly decryption but also now separate connection costs. 3) Use only native push service. GCM/FCM provide webpush. We could skip our own system in favor of a "pure" native implementation. Cons: Significantly complicates future mozilla services like pushbox and broadcast.
You need to log in before you can comment on or make changes to this bug.