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
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
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
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 → ---
I'll take a look. Thanks for reporting!
blocking 2.2+. Gaye to investigate
blocking-b2g: 2.2? → 2.2+
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.
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+
https://github.com/mozilla-b2g/gaia/commit/1570cba4545c00c74d11f2363ad4820fdf72dc14 all should be good to go now on master
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago → 4 years ago
Resolution: --- → FIXED
status-b2g-v2.2: unaffected → fixed
Target Milestone: --- → 2.2 S3 (9jan)
You need to log in before you can comment on or make changes to this bug.