Closed
Bug 817489
Opened 12 years ago
Closed 11 years ago
[Clock] Turn the active alarm in snooze mode when alarm goes off and user click power key down
Categories
(Firefox OS Graveyard :: Gaia::Clock, defect, P4)
Tracking
(blocking-basecamp:-, tracking-b2g:backlog)
RESOLVED
DUPLICATE
of bug 996092
People
(Reporter: iliu, Assigned: mcav)
References
Details
(Keywords: feature, Whiteboard: [p=3], ux-most-wanted, [priority])
If alarm goes off, and user click the power key down to turn off the screen...
What's the behavior going to be?
Reporter | ||
Comment 1•12 years ago
|
||
Hi Josh,
I need your definition for the user story.
When user turn the screen off, it will turn the vibration off(maybe another issue in platform) and still keep the ringtone on in current version.
I think it could be a issue there.
Please help to define it and re-assigne the issue to me.
Thank you.
Flags: needinfo?(jcarpenter)
Comment 2•12 years ago
|
||
Assignee is always the dev, not the needinfo requestee.
Josh, would you also judge whether this should block or not?
Assignee: jcarpenter → iliu
Comment 3•12 years ago
|
||
Hi Ian, good question. Here's my recommendation:
If device is LOCKED and screen is OFF:
* Alarm rings
* User presses hardware power button.
* Alarm state clears. Normal lock screen appears.
If device is UNLOCKED and screen is ON:
* Alarm rings
* User presses hardware power button.
* Alarm state clears. Device locks.
* If user turns device back on, the Alarm is not present.
Flags: needinfo?(jcarpenter)
Comment 4•12 years ago
|
||
BB+, P2 - incomplete use case to be completed
blocking-basecamp: ? → +
Priority: -- → P2
Comment 5•12 years ago
|
||
(In reply to Josh Carpenter [:jcarpenter] from comment #3)
> Hi Ian, good question. Here's my recommendation:
>
> If device is LOCKED and screen is OFF:
>
> * Alarm rings
> * User presses hardware power button.
> * Alarm state clears. Normal lock screen appears.
It's impossible for clock/dialer to cancel the power key press default action (turn off the screen). Can we instead implement:
* Alarm rings
* User presses hardware power button.
* Screen off, alarm enter snooze mode.
* X min later, the snooze alarm rings again.
> If device is UNLOCKED and screen is ON:
>
> * Alarm rings
> * User presses hardware power button.
> * Alarm state clears. Device locks.
> * If user turns device back on, the Alarm is not present.
This is essentially equal to turn off the alarm (hit "Close"), this is doable. But, I would recommend that we don't differentiate based on the lock state.
Flags: needinfo?(jcarpenter)
Comment 6•12 years ago
|
||
Mass Modify: All un-milestoned, unresolved blocking-basecamp+ bugs are being moved into the C3 milestone. Note that the target milestone does not mean that these bugs can't be resolved prior to 12/10, rather C2 bugs should be prioritized ahead of C3 bugs.
Target Milestone: --- → B2G C3 (12dec-1jan)
Comment 7•12 years ago
|
||
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #5)
> (In reply to Josh Carpenter [:jcarpenter] from comment #3)
> It's impossible for clock/dialer to cancel the power key press default
> action (turn off the screen). Can we instead implement:
>
> * Alarm rings
> * User presses hardware power button.
> * Screen off, alarm enter snooze mode.
> * X min later, the snooze alarm rings again.
Sure, that's a good work around for v1. Let's do that for both Locked and Unlocked circumstances.
Flags: needinfo?(jcarpenter)
Reporter | ||
Comment 8•12 years ago
|
||
Josh,
Thanks for your definition clearly.
I summarize the behavior for the two cases(device is locked/unlocked) again.
* Alarm rings
* User presses hardware power button.
* Screen off, alarm enter snooze mode.
* X min later, the snooze alarm rings again.
Let's do the change.
Summary: [Clock] What's the behavior of alarm goes off and user click power key down → [Clock] Turn the active alarm in snooze mode when alarm goes off and user click power key down
Comment 9•12 years ago
|
||
Perfect, thanks Ian!
Comment 10•12 years ago
|
||
I don't think we need to block on this for v1 given the user has the option to turn the alarm off via the screen itself.
Let's pick this up for the next release.
blocking-basecamp: + → -
Priority: P2 → P4
Target Milestone: B2G C3 (12dec-1jan) → ---
Updated•12 years ago
|
QA Contact: jshih → fyen
Comment 13•11 years ago
|
||
Activity in bug 820706 shows a patch that will introduce a "sleep-button-press" event—Ian are you still interested in working on this?
Reporter | ||
Comment 14•11 years ago
|
||
Sure. Once bug 820706 is landed, we're able to reach the event and do expected behavior.:)
Comment 15•11 years ago
|
||
Unfortunately it's r-ed because it's a hack :/
I will try to call for help on mail list :)
Assignee | ||
Updated•11 years ago
|
Assignee: iliu → nobody
Comment 16•11 years ago
|
||
I was wondering if this bug was fixed and I was testing it out on the phone. The alarm starts again when the x minutes are finished just like comment 8 said.
However, I am not sure if this is the expected behavior but this is what happened when I set an alarm and pressed the hardware button when the alarm started ringing. The screen first turned off but when I clicked the hardware button again, the alarm started ringing immediately. I was wondering if this was the expected behavior or a bug?
Flags: needinfo?(firefoxos-ux-bugzilla)
Comment 17•11 years ago
|
||
Flagging Juwei to clarify the expected behavior. Thanks!
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(jhuang)
Comment 18•11 years ago
|
||
No it shouldn't happen. The alarm should be snoozed all the way until X minutes finished.
The correct behaviour should be
* Alarm goes off
* User presses hardware power button
* Screen off , alarm enters snooze mode
* Screen on again, alarm UI off and won't ring until X mins are finished
Flags: needinfo?(jhuang)
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → m
Status: NEW → ASSIGNED
Target Milestone: --- → 1.4 S2 (28feb)
Assignee | ||
Updated•11 years ago
|
Whiteboard: [p=3]
Assignee | ||
Updated•11 years ago
|
Target Milestone: 1.4 S2 (28feb) → ---
Updated•11 years ago
|
Whiteboard: [p=3] → [p=3], ux-most-wanted
Assignee | ||
Updated•11 years ago
|
Updated•11 years ago
|
blocking-b2g: --- → backlog
Whiteboard: [p=3], ux-most-wanted → [p=3], ux-most-wanted, [priority]
Assignee | ||
Comment 19•11 years ago
|
||
Resolved in bug 996092, with Juwei's signoff.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Updated•10 years ago
|
blocking-b2g: backlog → ---
tracking-b2g:
--- → backlog
You need to log in
before you can comment on or make changes to this bug.
Description
•