819893 - [Gaia::Clock] Unable to close or snooze alarm after an user kills Clock app by Window Manager

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::System, defect, P3)

Description

[Dominic Kuo [:dkuo]]

Steps:

1. Setup an alarm.
2. Hold home button to trigger Window Manager, leave it and wait for the alarm to ring.
3. While the alarm is ringing, press home button to put it in background.
4. Kill Clock app by Window Manager.
5. Press notification to get alarm back to foreground.
6. Press close or snooze.

Result:

We are unable close the alarm window by pressing close or snooze buttons.

Comment 1

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

qawanted : do further testing please;
see if :
a) we get stuck due to the task manager being up
b) how stuck we are ... if we launch the clock app again, can you close the alarm?
c) what happens if the system closes the app, does the alarm behave in the same fashion?

Comment 2

[Ben Francis [:benfrancis]]

Naoki, any feedback on this?

Comment 3

[Al Tsai [:atsai]]

Here's the situation that I reproduce:

a) Got stuck at step 6, as description. I got a notification and never be able to shut it off.
b) Yes, I was able to re-launch the clock app again. I got the alarm pop to the top but I *cannot* shut it down.
I was still able to force close the app via Window Manager, and the situation would not changes.
c) As previously mentioned

The notification was there. The alarm popped to the top when the clock app launched, and all the things I can do was go back to home screen. I cannot access clock app anymore.

After the screen went off and woke it up again, the alarm covered the unlock screen. In other word, I cannot unlock screen anymore.

I'll say it's a blocker.

Comment 4

[Joe Cheng [:jcheng] (please needinfo)]

Triage: BB+, P3 base on comment 3 as it caused the phone not able to unlock

Comment 5

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I propose that we fix this in the system app attention screen handling; killing an app should bring down it's attention screen.

Ian, if you are loaded or unable to understand what I am proposing here I can take this issue.

Comment 6

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #5)
> I propose that we fix this in the system app attention screen handling;
> killing an app should bring down it's attention screen.
> 
> Ian, if you are loaded or unable to understand what I am proposing here I
> can take this issue.

Ping etienne; Ian told me that this approach does work for Clock app, but we don't know what would happen with the dialer app ...

Alternatively, we could just prevent people from closing the app with a attention screen from the cards view.

Comment 7

[[e-mail], [e-mail]]

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7129

Pointer to Github pull-request

Comment 8

[[e-mail], [e-mail]]

Comment on attachment 694744 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7129

1. We just prevent people from closing the app with a attention screen from the cards view.
2. User still can drag the each cards view. If the app has a attention screen, user cannot kill the app with swipe event

Comment 9

[Etienne Segonzac (:etienne)]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #6)
> (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #5)
> > I propose that we fix this in the system app attention screen handling;
> > killing an app should bring down it's attention screen.
> > 
> > Ian, if you are loaded or unable to understand what I am proposing here I
> > can take this issue.
> 
> Ping etienne; Ian told me that this approach does work for Clock app, but we
> don't know what would happen with the dialer app ...
> 
> Alternatively, we could just prevent people from closing the app with a
> attention screen from the cards view.

This sounds like a safer option for the Dialer.
Closing the attention screen window would leave the current call running with no UI at all to act on it.

Comment 10

[Etienne Segonzac (:etienne)]

Comment on attachment 694744 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7129

It's probably better to maintain an array or unkillable origins in the CardsView module by listening to the attentionscreenshow/attentionscreenhide events.

Bonus is, this will give us more flexibility if we want to tweak the UX (having a different style for unkillable cards/prevent the swiping movement all together) since we won't have to inspect the attention screen dom every time.

Comment 11

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 694744 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7129

I agree with Etienne.

Comment 12

[[e-mail], [e-mail]]

Comment on attachment 694744 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7129

I have revised my patch in the same pull request according Etienne's suggestion.
Could you help me to review my patch again?

Comment 13

[[e-mail], [e-mail]]

Comment on attachment 694744 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7129

I think the branch name is not fit with the purpose. Give up the pull request.

Comment 14

[[e-mail], [e-mail]]

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7171

Pointer to Github pull-request

Comment 15

[[e-mail], [e-mail]]

Comment on attachment 695415 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7171

Maintain an array for unkillable origins in the CardsView module by listening to the attentionscreenshow/attentionscreenhide events.

Comment 16

[[e-mail], [e-mail]]

Comment on attachment 694744 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7129

Branch name is not fit with the purpose.

Comment 17

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 695415 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7171

Please read comment at https://github.com/mozilla-b2g/gaia/pull/7129

attentive |əˈtentiv|
adjective
paying close attention to something: never before had she had such an attentive audience | Congress should be more attentive to the interests of taxpayers.
• assiduously attending to the comfort or wishes of others; very polite or courteous: the hotel has a pleasant atmosphere and attentive service.

Comment 18

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 695415 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7171

r=me commit 1b44be0

Comment 19

[[e-mail], [e-mail]]

Since the pr https://github.com/mozilla-b2g/gaia/pull/7171 is merged, close the issue now.

Note: 
The issue also happened in Dialer app, Bluetooth pairing(UI page with attention screen) with the reproduced steps.
I suggest that QA may verify them too.

Comment 20

[John Shih]

verified on Unagi
build info:
gaia master: 1be7bf421a6498f6e73377e3028227dea99b3431
b2g-18: e261861b0270

but I also found another related bug, please see bug 824567