Closed Bug 1362264 Opened 7 years ago Closed 7 years ago

No APNS notifications are received via AutoPush

Categories

(Firefox for iOS :: General, defect, P1)

Other
iOS
defect

Tracking

()

RESOLVED FIXED
Iteration:
1.22
Tracking Status
fxios 8.0+ ---

People

(Reporter: st3fan, Assigned: jhugman)

References

Details

Attachments

(1 file)

(Unclear if this is a client or server problem, so I filed this in the Client for now)

Firefox for iOS successfully registers itself with AutoPush and FxA but does not receive APNS messages when sending tabs from Desktop or Android.

Registration trace for AutoPush and FxA at:

  https://gist.github.com/st3fan/f7e1bc023f006743c96cd966492d509f

In the iOS Console logs I see messages like this:

  2017-05-04 22:51:14 -0400 apsd[82]: <APSTopicManager: 0x1003291e0>   setEnabledTopics:{(
      "org.mozilla.ios.FennecEnterprise"
  )} ignoredTopics:{(
  )} opportunisticTopics:{(
    "com.apple.mobilenotes",
    "com.apple.icloud-container.com.apple.mobilenotes",
    "com.google.Gmail",
    "com.apple.TestFlight"
  )} forCategory UsesALS pretend NO change Whitelisted

Which makes me confident that iOS is listening to incoming messages.

Sending a message from Desktop or Android does not generate any APNS (apsd) chatter in the console log. Nothing is received. No UIApplicationDelegate methods related to incoming notifications are called as a result.
Earlier today it looks like we did receive a full APNS message:

  2017-05-04 20:26:33 -0400 apsd[92]: <APSCourier: 0x1002059f0>: Received message for enabled topic 'org.mozilla.ios.FennecEnterprise' with payload '{
      aps =     {
          "content-available" = 1;
      };
      body = "oFUsGjKlLYWYEQPN9_hM-vA0TULB-xC5R4wUmRkx_Slilj0c-Kgb3zaiGQ2ku525bGd4lnJ80Ae2tM5__ERFRPryuStS372y8Y70kMAM8FrsDz-mY9DQ2s4iPDISQLf7MJjQIU7losA-0QVDDjTpC935KF_y4o0";
      chid = 29ebe6b905b942698b30b89cbb5f6a95;
      con = aesgcm;
      cryptokey = "keyid=p256dh;dh=BCBGNyP24B-VrFgDPdT6qOKH4C147iRxbqp9e2AulST2PXd7DJZfgj-5vV_7b-Flut_LlVc7kGIXkFvYKhe7dig;p256ecdsa=BHDgfiL1hz4oIBFaxxS9jkzyAVing-W9jjt_7WUeFjSW5U0UCODk5EjC8TQKddJNP3iow7UW6u8JE3t7u_y3Plc";
      enc = "keyid=p256dh;salt=f1wk30_bnXmdI6NsguFT2Q";
      ver = "gAAAAABZC8a4vcG5bXXJjZ_qWllC8fjMFiVk0L6xKyrvpakCcw0Ey2k5VJegu1pI8lhIxVwYcWa0AOEKfnHMTG4-8LmvSPMnbCcYS_l1Kxo3QVHVtZI5NZ4_UiD5BxwaOOTcUlVzHBK0uH0MqPx7FHnyEzbl16N8_awPoL4Pj-SvQQ8HR1qUFs68Skzbpghwo-qxE1plgJap";
   }' onInterface: NonCellular  for device token: NO  with priority 10

Both testing from Android and Desktop was done and it is unclear where this specific message originated.
Earier today :jrconlin noted the following:

  18:10  ok, latest push URL i've got is https://updates.push.services.mozilla.com/wpush/v1/gAAAAABZC53lV2Da4-aY27v48t3dgq9GMSA5ZKfqajOkphfMlDbMACDCJxE59WGAebz2GdHq83RH0_aZffAHWD8a5sZbpK9VV433sg_AWDcSTbm7qwiwLs3u23XLbhbF1RXFwQpoLvS5
  18:10 I'm not sure if that's yours, but you can try sending a curl -v -X POST to it and see if you get a message.
  18:11 oh, wait...
  18:11 that's returning a 502.
  18:11 meaning that it got rejected by apple.
  18:17 trying to see what I can find out about that error.
  18:20 APNS is reporting back "BadDeviceToken" for that url.

How do we trace this back? Is there any additional information that Apple's APNS gateway gives us?
Can we get a non-production environment going where we can do better debugging? What do we have and where should we test?
Is it possible that a notification with just aps = { "content-available": 1 } will only fire infrequently?

This is what Apple calls a "silent notification" and they say the following about it:

"Silent notifications are not meant as a way to keep your app awake in the background, nor are they meant for high priority updates. APNs treats silent notifications as low priority and may throttle their delivery altogether if the total number becomes excessive. The actual limits are dynamic and can change based on conditions, but try not to send more than a few notifications per hour."

This makes me think that silent notifications are not suitable for what we are trying to do.

Also, in the app delegate handler I see this:

    func application(_ application: ... fetchCompletionHandler) {
        log.info("APNS NOTIFICATION \(userInfo)")

        guard let profile = self.profile else {
            return completionHandler(.noData)
        }

        let handler = FxAPushMessageHandler(with: profile)
        handler.handle(userInfo: userInfo).upon { res in
            completionHandler(res.isSuccess ? .newData : .noData)
        }
    }

By returning .noData in case of an error, we signal iOS that this silent notification did not result in any action by the appliction. As a result, iOS will change the scheduling of silent notifications. And probably change the number of frequency of notifications that the app will actually recieve over APNS.


I think we may have to use normal visible notifications with an alert text.
Something to verify on our server side:

http://stackoverflow.com/a/41986764

When my app was moved from IOS 9 to IOS 10 the silent push notifications sent by my Parse server hosted on Heroku stopped being received by the app.

The only change I made to make notifications work again was to modify the Javascript on my server so that the argument to content-available was an integer 1 and not a string "1"

"If your notification payload contains the content-available key, your app will receive the notification if iOS or OS X determines it is energy-efficient to do so. If the energy or data budget for the device has been exceeded, your app will not receive any more notifications with the content-available key until the budget has been reset. This occurs once a day and cannot be changed by user or developer action. This throttle is disabled if the app is run from Xcode, so be sure to test your app by running it from the device to have the same user experience your customers will have."



I am more and more convinced that we cannot use silent notifictions with just a content-available value. I think these notifications are specifically for applications that need a server side trigger to update their content infrequently, and under strict control of iOS.

Unlike normal push notifications, they are severely rate limited. The reason for this is easy to explain: a normal push notification contains everything needed to display it, without starting up the app. A silent notification however always starts up the application and lets it run in the background for some time. The first is efficient and the latter is a battery killer if it happens often.

This also explains why I *did* get a notification through at one point when testing and not after that. The first one exhausted the silent notification budget that our app has. We may be able to verify this by simply waiting a good number of hours and then trying again.

This is really unfortunate and I think we could have caught this sooner by reading the documentation around notifictions.

I think we need to switch to regular notifications with an { alert: "You received a new tab" }. If possible.
It is possible that we will have to use the new

  https://developer.apple.com/reference/usernotifications/unnotificationserviceextension

to properly deal with this.
See Also: → 1354626
Assignee: nobody → jhugman
Status: NEW → ASSIGNED
Iteration: --- → 1.22
Priority: -- → P1
I think we are way past this bug, so I am closing it as resolved.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: