[Flame][Clock]The alarm item is still in checked status even though we tap Stop button after the alarm is rings

VERIFIED FIXED in 2.2 S8 (20mar)

Status

defect
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: jihao, Assigned: mcav)

Tracking

unspecified
2.2 S8 (20mar)
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-b2g:2.2+, b2g-v2.1 affected, b2g-v2.2 verified, b2g-master verified)

Details

Attachments

(4 attachments)

(Reporter)

Description

4 years ago
[1.Description]:
[Flame][v2.1&2.2][Clock] The alarm item is still in checked status even though we tap the stop button when alarm rings the second time, after we tap snooze button first time it rings.
Attachment: logcat_flame_1913.txt and uncheched.png
Occurrence time: 19:13 -- 19:19

[2.Testing Steps]: 
1. Open Clock.
2. Tap + button to add a alarm.
3. Set Repeat to be Never and the Time.
4. Tap Done button.
5. Wait until the alarm rings.
6. Tap Snooze button.
7. Wait 5 minutes.(Snooze time is by default)
8. The alarm rings again and tap Stop button.
9. Open Clock again.

[3.Expected Result]: 
The alarm item should be unchecked.

[4.Actual Result]: 
9. The alarm item displays in alarm list and is still in checked status.


[5.Reproduction build]: 
Flame 2.1build:
Gaia-Rev        73be51f998031f06db0cd660c0e388fa621c9f4c
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/ea426e47bfc4
Build-ID        20141228001253
Version         34.0

Flame 2.2 build:
Gaia-Rev        3554ea9504046646b4679e3a61317c49fc55ca87
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/67c42c076393
Build-ID        20141228010205
Version         37.0a1

[6.Reproduction Frequency]: 
Always Recurrence,5/5
TCID: Free Test
(Reporter)

Comment 1

4 years ago
Posted image unchecked.png
Hi Teri, Could you check if this is spec or something we can improve, thanks.
QA Whiteboard: [COM=Gaia::Clock]
Flags: needinfo?(twen)
This is a bug because here is not set repeat alarm, so here should be unchecked after tap stop button.
Flags: needinfo?(twen)
(Reporter)

Comment 4

4 years ago
I can reproduce this issue on latest Flame 2.1/2.2
Reproducing rate: 5/5
See New Log: logcat_flame_0956.txt

Environmental Variables:
Flame 2.1 build:
Build ID               20150212002013
Gaia Revision          88084bc7ef5ba6627dd09c774ef2f7fa96cbed71
Gaia Date              2015-02-11 15:02:07
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/e395bfad7bc9
Gecko Version          34.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150212.035634
Firmware Date          Thu Feb 12 03:56:45 EST 2015
Bootloader             L1TC000118D0
-------------------------------
Flame 2.2 build:
Gaia-Rev        791e53728cd8018f1d7cf7efe06bbeb1179f0370
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/5dec207fcbeb
Build-ID        20150212002504
Version         37.0a2
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150212.042208
FW-Date         Thu Feb 12 04:22:18 EST 2015
Bootloader      L1TC000118D0
Flags: needinfo?(echang)
A legacy bug, but confusing for user, set 2.2?
blocking-b2g: --- → 2.2?
Flags: needinfo?(echang)

Comment 6

4 years ago
Triage is blocking on this because it makes the user's alarm repeat indefinitely, and that it can't be turned off.
blocking-b2g: 2.2? → 2.2+

Updated

4 years ago
Duplicate of this bug: 1128331
(Assignee)

Updated

4 years ago
Assignee: nobody → m
Target Milestone: --- → 2.2 S8 (20mar)
The target milestone was configured as 2.2 S8 which is coming. Could you share the latest status with us? Thank you!
Flags: needinfo?(m)
(Assignee)

Comment 9

4 years ago
I haven't started on this yet; I expect to get to it tomorrow (Tuesday, US time) and the review should be done by Wednesday.
Flags: needinfo?(m)
(Assignee)

Comment 11

4 years ago
Comment on attachment 8578929 [details] [review]
[gaia] mcav:snooze-enabled > mozilla-b2g:master

Miller will be pleased to see that this patch has a test!

This was a straightforward logic bug where we didn't update the database to reflect the fact that a pendingly-snoozed alarm had already fired, causing the checkbox to remain checked, and users to remain confused. This wouldn't actually cause the alarm to continue firing (as was postulated by the concerns in comments here), but the box would remain checked until the alarm was interacted with again.

My Gaia::System patch from bug 1144396 is required to make the marionette test pass locally; otherwise it may intermittent, but I am confident that the test is correct and properly verifies the fix.

Additionally, due to bug 1035930, that particular marionette test is currently blacklisted. Based upon having been able to test this both manually and with marionette locally, I don't think it's a concern that it won't be running in CI; the alternative would involve delays and additional uplifts that I would consider not worth the additional risk.
Attachment #8578929 - Flags: review?(mmedeiros)
Comment on attachment 8578929 [details] [review]
[gaia] mcav:snooze-enabled > mozilla-b2g:master

LGTM! thanks!
Attachment #8578929 - Flags: review?(mmedeiros) → review+
(Assignee)

Updated

4 years ago
Keywords: checkin-needed
https://github.com/mozilla-b2g/gaia/pull/28930

Autolander could not land the pull request due to not having collaborator rights. This is possibly due to a tree closure. Please check the tree status and request checkin again once the tree is open.
(Assignee)

Updated

4 years ago
Keywords: checkin-needed
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
(Assignee)

Comment 15

4 years ago
Comment on attachment 8578929 [details] [review]
[gaia] mcav:snooze-enabled > mozilla-b2g:master

[Approval Request Comment]

[Bug caused by] (feature/regressing bug #): -

[User impact] if declined:

Users' alarm list will show an alarm as enabled when it is not.

[Testing completed]:

Automated + Manual

[Risk to taking this patch] (and alternatives if risky):

low

[String changes made]:

none
Attachment #8578929 - Flags: approval-gaia-v2.2?
Attachment #8578929 - Flags: approval-gaia-v2.2? → approval-gaia-v2.2+
This issue is verified fixed on the latest Nightly Flame 3.0 and 2.2 builds.

Actual Results: The alarm is unchecked after stopping it with no repeat schedule set.

Environmental Variables:
Device: Flame 3.0
BuildID: 20150323010204
Gaia: 9b6f3024e4d0e62dd057231f4b14abe1782932ab
Gecko: e730012260a4
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 39.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0

Environmental Variables:
Device: Flame 2.2
BuildID: 20150323002504
Gaia: 7f367fc98ffdd183f21d2cdfe20556ab877ece34
Gecko: 3ea0eaeda353
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
Status: RESOLVED → VERIFIED
Flags: needinfo?(ktucker)
QA Whiteboard: [COM=Gaia::Clock] → [QAnalyst-Triage?][COM=Gaia::Clock]
QA Whiteboard: [QAnalyst-Triage?][COM=Gaia::Clock] → [QAnalyst-Triage+][COM=Gaia::Clock]
Flags: needinfo?(ktucker)
You need to log in before you can comment on or make changes to this bug.