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)

Other
iOS
defect

Tracking

()

VERIFIED FIXED
Tracking Status
fxios 10.0 ---
fxios-v10.0 --- affected

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.
I've just reproduced this issue by doing a few consecutive disconnects/re-connects on desktop.
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: nobody → jdarcangelo
Status: NEW → ASSIGNED
Priority: -- → P1
Attached file GitHub Pull Request
Attachment #8922480 - Flags: review?(sarentz)
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+
Catalin, please re-test with latest builds with my patch applied. Thanks!
Flags: needinfo?(catalin.suciu)
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.}
Re-opening this since we're still actively investigating.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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 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+
Carrying over R+ from :st3fan on Slack.
Attachment #8924701 - Flags: review+
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.

Attachment

General

Created:
Updated:
Size: