Closed Bug 1301558 Opened 3 years ago Closed 3 years ago

Push messages aren't processed when Fennec is not running

Categories

(Firefox for Android :: General, defect, P3)

defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: Grisha, Assigned: Grisha)

References

Details

(Whiteboard: [MobileAS][send-tab])

Attachments

(1 file)

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) }
Assignee: nobody → gkruglov
Status: NEW → ASSIGNED
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.
Attachment #8789915 - Flags: review?(nalexander) → review+
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.
Blocks: 1297454
Closing for now, and will re-open in the odd case this crops up again.
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Priority: P1 → P3
Resolution: --- → WORKSFORME
Duplicate of this bug: 1306340
You need to log in before you can comment on or make changes to this bug.