Closed
Bug 1411549
Opened 8 years ago
Closed 8 years ago
Empty notification received after re-connecting the account on desktop
Categories
(Firefox for iOS :: General, defect, P1)
Tracking
()
VERIFIED
FIXED
People
(Reporter: csuciu, Assigned: justindarc)
Details
Attachments
(5 files)
v10.0 (7233)
iPad Air 2 (10.3.3)
1. Connect account A on desktop.
2. Connect account A on iOS.
3. Sync both clients.
4. Disconnect/re-connect a few times on desktop.
=> See the push notifications being received correctly on iOS.
5. Disconnect on desktop.
5. Re-connect on desktop after ~ 30 minutes
Result: An empty notification is received on iOS.
I was able to reproduce this issue in 2/4 tries.
| Reporter | ||
Comment 1•8 years ago
|
||
I've just reproduced this issue by doing a few consecutive disconnects/re-connects on desktop.
| Assignee | ||
Comment 2•8 years ago
|
||
Most relevant bits:
default 14:52:03.072346 -0400 SpringBoard [org.mozilla.ios.Fennec.NotificationService] Beginning extension session...
and ~1sec later:
error 14:52:04.071630 -0400 SpringBoard [org.mozilla.ios.Fennec.NotificationService] Extension will be killed due to sluggish startup
error 14:52:04.560174 -0400 SpringBoard Hub connection error Error Domain=NSCocoaErrorDomain Code=4097 "connection to service named org.mozilla.ios.Fennec.NotificationService" UserInfo={NSDebugDescription=connection to service named org.mozilla.ios.Fennec.NotificationService}
| Assignee | ||
Updated•8 years ago
|
| Assignee | ||
Comment 3•8 years ago
|
||
Attachment #8922480 -
Flags: review?(sarentz)
Comment 4•8 years ago
|
||
Comment on attachment 8922480 [details] [review]
GitHub Pull Request
Looks good - just added some small questions to the PR.
Attachment #8922480 -
Flags: review?(sarentz) → review+
| Assignee | ||
Comment 5•8 years ago
|
||
Landed on master:
https://github.com/mozilla-mobile/firefox-ios/commit/9966bf5c25c2b426497af875568c5e50308803a4
Landed on v10.x:
https://github.com/mozilla-mobile/firefox-ios/commit/5a782f55fd0767d5caf16fa3482c49b228e5b4c7
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
| Assignee | ||
Comment 6•8 years ago
|
||
Catalin, please re-test with latest builds with my patch applied. Thanks!
Flags: needinfo?(catalin.suciu)
Comment 7•8 years ago
|
||
Extension error whilst trying to modify push notification A68B-356E: Error Domain=NSCocoaErrorDomain Code=4099 "The connection from pid 1448 was invalidated from this process." UserInfo={NSDebugDescription=The connection from pid 1448 was invalidated from this process.}
| Assignee | ||
Comment 8•8 years ago
|
||
Re-opening this since we're still actively investigating.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
| Assignee | ||
Comment 9•8 years ago
|
||
It's unclear at this point if this will resolve our issue, but in local builds, this PR reduces the size of NotificationService.appex from 1.2MB down to 970KB. Cold launches (i.e. first notification received after installing) seems to consistently take ~300ms on my iPhone 6S running iOS 11.0.3 with this patch and subsequent launches take roughly ~50ms. This doesn't seem to be *that* much of an improvement over master, but it is a bit more consistent. I have not seen any blank notifications with this patch applied which means that all launches of NotificationService come in at under the 1000ms cut-off.
The methodology I used to measure these times is as follows:
1. Install local Fennec build with patch applied
2. Connect device to Mac and open Console.app
3. Filter on "NotificationService"
4. When a notification is first received by the OS, a message will be logged by SpringBoard that looks like:
`default 15:45:20.508870 -0400 SpringBoard [org.mozilla.ios.Fennec.NotificationService] Beginning extension session...`
5. As soon as the NotificationService process has finished launching, another message will be logged by SpringBoard that looks like:
`default 15:45:20.547867 -0400 SpringBoard [org.mozilla.ios.Fennec.NotificationService] Extension session created successfully for UUID FE14999B-0B2A-4570-95B0-89A55E719EA9`
6. Subtract the timestamps between the two messages to get an approximation of startup time for NotificationService
Note, if NotificationService takes longer than 1000ms to launch, you won't see the "Extension session created successfully" message. Instead, you'll see a message logged by SpringBoard that looks like:
`error 14:52:04.071630 -0400 SpringBoard [org.mozilla.ios.Fennec.NotificationService] Extension will be killed due to sluggish startup`
Anytime I've observed the "killed due to sluggish startup" message, the difference between its timestamp and that of the "Beginning extension session" message is just shy of 1000ms. However, I have not yet seen this happen with this patch applied so hopefully this will resolve it (*fingers crossed*).
Attachment #8924010 -
Flags: review?(jhugman)
Comment 10•8 years ago
|
||
Comment on attachment 8924010 [details] [review]
Let's try this again - GitHub Pull Request
LGTM.
I'd add a herebedragons comment at the top of Profile. (see PR)
Attachment #8924010 -
Flags: review?(jhugman) → review+
| Assignee | ||
Comment 11•8 years ago
|
||
Landed on master:
https://github.com/mozilla-mobile/firefox-ios/commit/1f0f709c959f68043c91477106af47b4875d5f0d
Landed on v10.x:
https://github.com/mozilla-mobile/firefox-ios/commit/fe8b9f251ff0955d2da13362b783ab32059603a2
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
Resolution: --- → FIXED
| Assignee | ||
Comment 12•8 years ago
|
||
Carrying over R+ from :st3fan on Slack.
Attachment #8924701 -
Flags: review+
| Assignee | ||
Comment 13•8 years ago
|
||
Landed attachment #8924701 [details] [review] on master:
https://github.com/mozilla-mobile/firefox-ios/commit/aeb80d641282df23cd19a24e23abee08a61aa1ad
Landed attachment #8924701 [details] [review] on v10.x:
https://github.com/mozilla-mobile/firefox-ios/commit/bda2844b3688a9a8cfdf122a2b8a612b5cbe8c41
| Reporter | ||
Comment 14•8 years ago
|
||
Following the STRs from the description and comment #1, I'm no longer able to reproduce the bug.
Status: RESOLVED → VERIFIED
Flags: needinfo?(catalin.suciu)
You need to log in
before you can comment on or make changes to this bug.
Description
•