User Agent: Mozilla/5.0 (X11; Linux i686; rv:35.0) Gecko/20100101 Firefox/35.0 Build ID: 20150126180325 Steps to reproduce: - Schedule a new alarm in 2 minutes: navigator.mozAlarms.add(...). - Power off the device and wait 5 minutes. - Power up the device. Actual results: Nothing. Expected results: The mozSetMessageHandler('alarm') of the app should be executed. According to the wiki https://wiki.mozilla.org/WebAPI/AlarmAPI#FAQ : « Supposing an alarm is set at 8:00am, but the device shuts down from 7:00am to 9:00am. Will the Alarm API fire an "alarm" message for that when the device powers up next time? - Yes, it will fire as soon as the device powers up. » This is confusing. I have to manually start the app (my app as well the calendar or the clock) to handle the alarm message. The application is not automatically handling the message as it does if I do not power off the device and simply close the application. What about this use case: when the device powers up, waking up an application and running a task scheduled when the device was off. The fact that the date has passed (that the device was off) is not really important. The task must be performed after the reboot if the date has passed (or during the correct date after the reboot). So, this problem looks to be the same with a custom application, calendar or the clock. Tested with simulator 2.0, 2.1 and on GP Keon with nightly's 3.0 (current 2015-02-07.Gecko-37dc6c9.Gaia-bbc853f). I don't know what should be the correct behavior of Firefox OS because the following bug is related to the opposite (the behavior I'm expecting :) : https://bugzilla.mozilla.org/show_bug.cgi?id=924474

(In reply to pumpkin from comment #0) > I don't know what should be the correct behavior of Firefox OS because the > following bug is related to the opposite (the behavior I'm expecting :) : > https://bugzilla.mozilla.org/show_bug.cgi?id=924474 That issue sounds specific to the Gaia Clock app, not the Alarms API generally (although I'm not sure how the Clock app triggers the notification, given this bug). We see this in PluotSorbet too <https://github.com/mozilla/pluotsorbet/issues/1767>. Confirming and moving to the product/component of the original Alarm API implementation bug 749551.

System app bug 1160923, mozAlarms is innocent (in this case! ;). Duping over.