The default bug view has changed. See this FAQ.

Alarm API - If an alarm cannot be fired when the device shuts down, it should be fired when powering up.

RESOLVED FIXED in mozilla17

Status

()

Core
DOM: Device Interfaces
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: Gene Lian (I already quit Mozilla), Assigned: Gene Lian (I already quit Mozilla))

Tracking

Trunk
mozilla17
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [LOE:S])

Attachments

(1 attachment)

(Assignee)

Description

5 years ago
Please see: https://groups.google.com/d/msg/mozilla.dev.webapi/pkx1uz_pnhQ/qzCco0g1414J
(Assignee)

Updated

5 years ago
Blocks: 749551
(Assignee)

Updated

5 years ago
Summary: Alarm API - If an alarm cannot be fired when the device shuts down, if should be fired when powering up. → Alarm API - If an alarm cannot be fired when the device shuts down, it should be fired when powering up.
(Assignee)

Comment 1

5 years ago
Hi Fabrice,

We encountered an interesting problem when solving this. If we attempt to fire a system message when the device is "powering up", the shell's observer can receive "system-messages-open-app" but cannot further open the Alarm-Colock app because the Gaia's window_manager.js has not yet been ready for catching the "open-app". Under this circumstance, we have to manually open the Alarm-Clock app and then it can response to the pending system message.

Sending the system message in a delayed 10 seconds will work (from Alarm API), but it doesn't sound an optimal approach. Any better solution to tackle the problem?
(In reply to Gene Lian [:gene] from comment #1)

> Sending the system message in a delayed 10 seconds will work (from Alarm
> API), but it doesn't sound an optimal approach. Any better solution to
> tackle the problem?

It looks like we should buffer messages in shell.js until the system app has started.
(Assignee)

Comment 3

5 years ago
(In reply to Fabrice Desré [:fabrice] from comment #2)
> (In reply to Gene Lian [:gene] from comment #1)
> 
> > Sending the system message in a delayed 10 seconds will work (from Alarm
> > API), but it doesn't sound an optimal approach. Any better solution to
> > tackle the problem?
> 
> It looks like we should buffer messages in shell.js until the system app has
> started.

Sounds good! But how to detect if the system app has been started or not in shell.js? Can we really do that at the platform level?
(Assignee)

Comment 4

5 years ago
(In reply to Gene Lian [:gene] from comment #3)
> (In reply to Fabrice Desré [:fabrice] from comment #2)
> > (In reply to Gene Lian [:gene] from comment #1)
> > 
> > > Sending the system message in a delayed 10 seconds will work (from Alarm
> > > API), but it doesn't sound an optimal approach. Any better solution to
> > > tackle the problem?
> > 
> > It looks like we should buffer messages in shell.js until the system app has
> > started.
> 
> Sounds good! But how to detect if the system app has been started or not in
> shell.js? Can we really do that at the platform level?

Respond to myself: I think we can follow something like http://mxr.mozilla.org/mozilla-central/source/b2g/chrome/content/shell.js#121 to listen to an "onload" event. As mentioned by Fabrice, We won't send "open-app" chromEvent until "onload" event is caught.
(Assignee)

Updated

5 years ago
Depends on: 783149
(Assignee)

Comment 5

5 years ago
Created attachment 652301 [details] [diff] [review]
Patch

Hi Vivien,

Changes are super trivial:

1. Fire alarms that should have been fired during power-down and remove it from DB.

2. To decide if alarms are expired by comparing them with a more precise Date.now().

3. Although we still have a potential issue at comment #1, I've already fired another bug to keep track of that. For the Alarm API part, these changes are for sure.

Thanks very much for your review again :)
Assignee: nobody → clian
Attachment #652301 - Flags: review?(21)
(Assignee)

Updated

5 years ago
Whiteboard: [LOE:S]
Attachment #652301 - Flags: review?(21) → review+
(Assignee)

Updated

5 years ago
Keywords: checkin-needed
https://hg.mozilla.org/integration/mozilla-inbound/rev/d51a3bf72b9c
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/d51a3bf72b9c
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
(Assignee)

Updated

5 years ago
No longer depends on: 783149
(Assignee)

Updated

5 years ago
Depends on: 783149
You need to log in before you can comment on or make changes to this bug.