We currently do not receive push messages in two cases: - fennec is not running (device just booted, user didn't start the browser) - fennec was force stopped (package in "stopped" state) If fennec was force stopped, I'm not sure we can do anything other than hope user restarts Fennec. Using WakefulBroadcastReceiver instead of GcmListenerService might work if we were simply not started, from what I'm reading - I'll try this approach and report back. Furthermore, if push message ("send tab" command, for example) is received by device in this state, it's dropped on the floor, and when user starts up Fennec afterwards it is no longer accessible in any way. The only way to receive the tab at this point is to trigger a sync, or send another tab (which will be received and will trigger a sync). It seems that part of the "problem" is that GCM messages work "better" with an actual notification that could be displayed by Android itself - and we only have an encrypted payload. Exhibit A, push message being dropped on the floor while fennec isn't running: 09-08 14:50:54.591 4173 4173 W GCM-DMM : broadcast intent callback: result=CANCELLED forIntent { act=com.google.android.c2dm.intent.RECEIVE pkg=org.mozilla.fennec_grisha (has extras) }

Setting up a wakeful broadcast receiver which starts up an exported service to handle incoming GCM intent works. It's rather heavy-handed - we startup Gecko in order to process the message, but I think that is inevitable without necessary java-side crypto.

Hmm, while starting up gecko to process incoming FxA push message is fine, doing that for incoming webpush messages is probably not.

(In reply to :Grisha Kruglov from comment #3) > Hmm, while starting up gecko to process incoming FxA push message is fine, > doing that for incoming webpush messages is probably not. It should be okay. The Push integration gets to decide if the service worker is reputable enough to handle background pushes (most aren't, perhaps all at this time); and the service worker that handles the Web Push message can determine whether it has visible windows in order to avoid doing UI work.

Comment on attachment 8789915 [details] Bug 1301558 - Use WakefulBroadcastReceiver to process incoming push intents https://reviewboard.mozilla.org/r/77960/#review76438 I'm not thrilled by this, but many other people on the web seem to report the same findings. So sad.

Comment on attachment 8789915 [details] Bug 1301558 - Use WakefulBroadcastReceiver to process incoming push intents https://reviewboard.mozilla.org/r/77960/#review76498 ::: mobile/android/base/GcmAndroidManifest_services.xml.in:27 (Diff revision 2) > </receiver> > > - <!-- Handle messages directed by the GCM receiver. --> > + <!-- Handle all inbound RECEIVE intents. --> > + <receiver > + android:name="org.mozilla.gecko.gcm.GcmWakefulBroadcastReceiver" > + android:exported="true"> Now that I think further, we must be very sure that we sanitize incoming intents very thoroughly. We already needed to do this since the receiver was exported, but notice that this new receiver is not permission protected. I'd like to discuss this further with another Android dev (sebastian?) before we land any changes.

(In reply to Nick Alexander :nalexander from comment #7) > Comment on attachment 8789915 [details] > Bug 1301558 - Use WakefulBroadcastReceiver to process incoming push intents > > https://reviewboard.mozilla.org/r/77960/#review76498 > > ::: mobile/android/base/GcmAndroidManifest_services.xml.in:27 > (Diff revision 2) > > </receiver> > > > > - <!-- Handle messages directed by the GCM receiver. --> > > + <!-- Handle all inbound RECEIVE intents. --> > > + <receiver > > + android:name="org.mozilla.gecko.gcm.GcmWakefulBroadcastReceiver" > > + android:exported="true"> > > Now that I think further, we must be very sure that we sanitize incoming > intents very thoroughly. We already needed to do this since the receiver > was exported, but notice that this new receiver is not permission protected. > > I'd like to discuss this further with another Android dev (sebastian?) > before we land any changes. I'm having problems replicating the behaviour I (... might have...?) observed; it's possible that the only "dropping push messages" scenario has been indeed when fennec is force-stopped. If that's the case, this change is not needed, and won't be landed. I'll try to gather evidence for the contrary, but in the meantime this is a no-op.

Closing for now, and will re-open in the odd case this crops up again.