calendar no longer gives me notifications unless I explicitly start calendar after booting phone

RESOLVED FIXED in Firefox OS v2.2

Status

RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: dbaron, Assigned: gaye)

Tracking

({regression})

unspecified
2.2 S3 (9jan)
regression

Firefox Tracking Flags

(blocking-b2g:2.2+, b2g-v2.0 unaffected, b2g-v2.1 unaffected, b2g-v2.2 fixed)

Details

Attachments

(1 attachment)

Sometime within the past few weeks the calendar app has regressed so that I no longer get calendar alarms unless I explicitly start the calendar app after booting the phone.

(This used to be true a while ago, see bug 1003978, but the calendar had worked pretty reliably for quite a while until the past week or two.)

I'm running master, userdebug, using my old builds, on a Flame.
QA-Wanted for a branch check
Keywords: qawanted
QA Contact: ddixon
Branch Check 

STR used: 
1. Open Calendar app
2. Sign into an online calender
3. Create an event that will trigger an alarm/notification

Note:  The Online Calendar and the Offline Calendar were tested for the brach check here. 

Repro attempts: 0/10 

Unable to reproduce issue in latest Flame 2.2, 2.1, 2.0 (shallow flash, engineering, 319 MB memory).

Device: Flame 2.2
BuildID: 20141209040946
Gaia: 9e0b96c7b61c7ff943876ca93e2596d972437b80
Gecko: 47f0671e2c65
Version: 37.0a1 (2.2)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
----------------------------------------------
Device: Flame 2.1
BuildID: 20141209084847
Gaia: 155424d51cf9bb2ea41dc6667f94741f82f35bc0
Gecko: fe5329227c54
Version: 34.0 (2.1) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
----------------------------------------------
Device: Flame 2.0
BuildID: 20141208061237
Gaia: 856863962362030174bae4e03d59c3ebbc182473
Gecko: 2d0860bd0225
Version: 32.0 (2.0) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.0: --- → unaffected
status-b2g-v2.1: --- → unaffected
status-b2g-v2.2: --- → unaffected
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
QA Contact: ddixon
(In reply to Duane Dixon [:ddixon] from comment #2)
> STR used: 
> 1. Open Calendar app
> 2. Sign into an online calender
> 3. Create an event that will trigger an alarm/notification

Those steps to reproduce aren't appropriate for testing this bug.
That said, this seems to have gotten better sometime in the past 2 weeks.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
And it's back.

I think this is just intermittent, and I don't know what the conditions are.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(Assignee)

Comment 6

4 years ago
I'll take a look. Thanks for reporting!
(Assignee)

Updated

4 years ago
Assignee: nobody → gaye

Updated

4 years ago
Duplicate of this bug: 1110527

Comment 8

4 years ago
blocking 2.2+.  Gaye to investigate
blocking-b2g: 2.2? → 2.2+
(Assignee)

Comment 9

4 years ago
I am having trouble reproducing since I'm running into some device time issues. I do know that if I

(1) create an event with a reminder that should fire in a few minutes
(2) close calendar app
(3) wait for a few minutes

The event does fire. There could still be an issue if the device is restarted between 2 and 3.
(Assignee)

Comment 10

4 years ago
Created attachment 8540890 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/26978

Patch makes the mozSetMessageHandler handler wait for someone to be ready to consume 'alarm' and 'notification' events before emitting so that we avoid the race condition where the controllers aren't ready to handle messages being emitted from message_handler.js.
Attachment #8540890 - Flags: review?(mmedeiros)
Comment on attachment 8540890 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/26978

code changes LGTM. problem was likely caused because of a timeout related to the way the system clock works.. :gaye increased the maximum delay and also updated alameda to use the native promises (which should bypass the system clock problem).
Attachment #8540890 - Flags: review?(mmedeiros) → review+
(Assignee)

Comment 12

4 years ago
https://github.com/mozilla-b2g/gaia/commit/1570cba4545c00c74d11f2363ad4820fdf72dc14 all should be good to go now on master
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago4 years ago
Resolution: --- → FIXED
status-b2g-v2.2: unaffected → fixed
Target Milestone: --- → 2.2 S3 (9jan)
Blocks: 1111093
You need to log in before you can comment on or make changes to this bug.