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)
Tracking
()
RESOLVED
FIXED
Iteration:
1.22
Tracking | Status | |
---|---|---|
fxios | 8.0+ | --- |
People
(Reporter: st3fan, Assigned: jhugman)
References
Details
Attachments
(1 file)
666 bytes,
text/plain
|
Details |
(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.
Reporter | ||
Comment 1•7 years ago
|
||
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.
Reporter | ||
Comment 2•7 years ago
|
||
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?
Reporter | ||
Comment 3•7 years ago
|
||
Can we get a non-production environment going where we can do better debugging? What do we have and where should we test?
Reporter | ||
Comment 4•7 years ago
|
||
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.
Reporter | ||
Comment 5•7 years ago
|
||
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"
Reporter | ||
Comment 6•7 years ago
|
||
"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.
Reporter | ||
Comment 7•7 years ago
|
||
It is possible that we will have to use the new https://developer.apple.com/reference/usernotifications/unnotificationserviceextension to properly deal with this.
Assignee | ||
Comment 8•7 years ago
|
||
Assignee | ||
Updated•7 years ago
|
Assignee: nobody → jhugman
Status: NEW → ASSIGNED
Assignee | ||
Updated•7 years ago
|
Iteration: --- → 1.22
Updated•7 years ago
|
Priority: -- → P1
Reporter | ||
Comment 9•7 years ago
|
||
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.
Description
•