979102 - [B2G][Clock] If a user lets an alarm go off for 10 minutes without stopping it, the stop and snooze buttons will stop functioning

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Clock, defect)

Description

[KTucker [:KTucker][Inactive 3/4/2016]]

Attachment: AlarmLog.txt

Description:
If a user lets an alarm go off for 10 minutes without stopping it, the "Stop" and "Snooze" buttons will stop functioning. Also, the user cannot force close the clock app so they will have to restart their device. 

Repro Steps:
1)  Updated Buri to Build ID: 20140227040202
2)  Tap on the "Clock" app.
3)  Create an alarm.
4)  When the alarm goes off, do not tap "Stop or "Snooze".
5)  Let the alarm go off for at least 10 minutes. (The alarm tone will stop and the device will go to sleep.)
6)  Wake the phone back up and try to tap on the "Stop" and "Snooze" buttons. 
7)  Try to force close the "Clock" app. 

Actual:
The "Stop" and "Snooze" buttons will stop functioning if the user lets the alarm go off for 10 minutes straight. 

Expected:
The "Stop" and "Snooze" buttons remain functional regardless of how long an alarm goes off on the phone. 

Environmental Variables
Device: Mozilla 1.4.0 Mozilla RIL
Build ID: 20140227040202
Gecko: https://hg.mozilla.org/mozilla-central/rev/a98a1d78817f
Gaia: 22d48b62df7901ad45044f66e15e7d8943884a06
Platform Version: 30.0a1
Firmware Version: v1.2-device.cfg

Notes:
Repro frequency: 100%
Link to failed test case: https://moztrap.mozilla.org/manage/case/4371/
See attached: logcat

Comment 1

[KTucker [:KTucker][Inactive 3/4/2016]]

This issue does not occur on the Buri v 1.3.0 Mozilla RIL

Device: Buri 1.3 Mozilla RIL
BuildID: 20140303004002
Gaia: 539a25e1887b902b8b25038c547048e691bd97f6
Gecko: eb43649f2837
Version: 26.0
Firmware Version: v1.2-device.cfg

The "Snooze" and "Stop" buttons remained functional after letting the alarm go off for over 10 minutes.

Comment 2

[Sarah Parsons]

Removing regressionwindow-wanted and adding QA Wanted to get reduced STR.

Comment 3

[Brogan Zumwalt [Inactive]]

This issue appears to only occur after ten minutes. I was able to get back to the homescreen without restarting, but a opening the clock app resulted in alarm screen with "close" and "snooze" buttons. While attempting to reopen clock app the logcat shows "out of pmem" and other errors. I have included these below:

03-04 11:05:17.528: E/QCALOG(194): [MessageQ] ProcessNewMessage: [XTWWAN-PE] unknown deliver target [OS-Agent]
03-04 11:05:18.168: E/GeckoConsole(136): Content JS WARN at app://system.gaiamobile.org/js/app_window_manager.js:85 in awm_display: the app has been displayed.
03-04 11:05:19.938: E/GeckoConsole(136): Content JS WARN at app://system.gaiamobile.org/js/app_window_manager.js:85 in awm_display: the app has been displayed.
03-04 11:05:20.258: E/memalloc(136): /dev/pmem: No more pmem available
03-04 11:05:20.258: W/memalloc(136): Falling back to ashmem
03-04 11:05:20.268: E/memalloc(136): /dev/pmem: No more pmem available
03-04 11:05:20.268: W/memalloc(136): Falling back to ashmem
03-04 11:05:20.288: E/memalloc(136): /dev/pmem: No more pmem available
03-04 11:05:20.288: W/memalloc(136): Falling back to ashmem
03-04 11:05:20.308: I/Gonk(136): Setting nice for pid 382 to 18
03-04 11:05:20.308: I/Gonk(136): Changed nice for pid 382 from 1 to 18.
03-04 11:05:20.388: E/memalloc(136): /dev/pmem: No more pmem available
03-04 11:05:20.388: W/memalloc(136): Falling back to ashmem
03-04 11:05:20.498: E/msm7627a.hwcomposer(136): hwc_set: Unable to render by hwc due to non-pmem memory
03-04 11:05:20.498: E/memalloc(136): /dev/pmem: No more pmem available
03-04 11:05:20.498: W/memalloc(136): Falling back to ashmem
03-04 11:05:20.518: E/msm7627a.hwcomposer(136): hwc_set: Unable to render by hwc due to non-pmem memory
03-04 11:05:20.518: E/memalloc(136): /dev/pmem: No more pmem available
03-04 11:05:20.518: W/memalloc(136): Falling back to ashmem
03-04 11:05:20.538: E/msm7627a.hwcomposer(136): hwc_set: Unable to render by hwc due to non-pmem memory
03-04 11:05:20.558: E/msm7627a.hwcomposer(136): hwc_set: Unable to render by hwc due to non-pmem memory
03-04 11:05:20.568: E/msm7627a.hwcomposer(136): hwc_set: Unable to render by hwc due to non-pmem memory
03-04 11:05:22.498: E/QCALOG(194): [MessageQ] ProcessNewMessage: [XTWiFi-PE] unknown deliver target [OS-Agent]

In addition the notification/status bar was not visible, being replaced by what appeared to be a portion of the alarm screen. Unable to pull down notification window.

Environmental Variables:
Device: Buri v1.4 Master Mozilla RIL
BuildID: 20140304040200
Gaia: 6df4533f14ec2645bb13d8a803a5151583ca13a8
Gecko: 529b86b92b1d
Version: 30.0a1
Firmware Version: v1.2-device.cfg

Comment 4

[Marcus Cavanaugh [:mcav]]

Attachment: Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/16867

This bug was caused by a couple of issues:

- The clock app holds a wakelock when the alarm goes off. When that wakelock expired, previously it would try to call .stopNotify(), which killed the click handlers for the buttons but did not actually close the window.

- The event handling for the buttons was broken in a few ways.

An integration test covers this case.

Comment 5

[Miller Medeiros [:millermedeiros]]

Comment on attachment 8385691 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/16867

looks good to me. improved overall code structure and added a test to make sure user can click the "stop" button.

Comment 6

[Marcus Cavanaugh [:mcav]]

Thanks! Landed:

https://github.com/mozilla-b2g/gaia/commit/86880cf7b133a245963975547337ab3bb1526f56

Comment 7

[Edward Chen[:edchen]]

[Environment]
Gaia      6c109df47006b08c082761c0ddd6ba53a864983a
Gecko     https://hg.mozilla.org/mozilla-central/rev/21f293fc8d34
BuildID   20140309160201
Version   30.0a1
ro.build.version.incremental=eng.archermind.20131114.105818
ro.build.date=Thu Nov 14 10:58:33 CST 2013


[Result]
PASS

The bug fixed, I marked it to "Verified".