1026167 - [B2G] [Clock] Phone calls can be interrupted by clock alarms

Status: RESOLVED INVALID

(Firefox OS Graveyard :: AudioChannel, defect)

Description

[Chris Kreinbring [:CKreinbring]]

Attachment: Log of clock alarm interrupting phone call

Description:
If a clock alarm goes off while the user is in the middle of a call, the alarm will be audible and visible on the device.

Repro Steps:
1) Update Flame to Build ID: 20140616000203
2) Launch the Clock app.
3) Tap the New Alarm icon and set an alarm a couple of minutes into the future.
4) Call the test device from another device and pick up the call.
5) Wait for the time set on the alarm and observe the screen when the time comes.

Actual:
The alarm page appears, the device vibrates if the option was enabled, and beeping can be heard from the device.

Expected:
The call continues with no alarm reaction from the device.

Environmental Variables
Device: Flame 2.0
Build ID: 20140616000203
Gecko: https://hg.mozilla.org/releases/mozilla-aurora/rev/52a276202888
Gaia: a6988c15b361938bea5976c846c147ecdc1121c0
Platform Version: 32.0a2
Firmware Version: v121-2
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Notes:
Repro frequency: 100%
Link to failed test case: https://moztrap.mozilla.org/manage/case/4500/
See attached video clip and logcat logs

Comment 1

[Chris Kreinbring [:CKreinbring]]

Repros on Flame 2.1, Open C 2.0 and Buri 2.0 mozilla RIL.  Does not repro on Flame 1.4, the alarm does not appear until the end of the call.

Flame 2.1
Build ID: 20140616040202
Gecko: https://hg.mozilla.org/mozilla-central/rev/80431d4fd0da
Gaia: dfc4703bb81d1fa4f2087a1a6124b47a80a5d1de
Platform Version: 33.0a1
Firmware Version: v121-2
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Open C 2.0 
Build ID: 20140616000203
Gecko: https://hg.mozilla.org/releases/mozilla-aurora/rev/52a276202888
Gaia: a6988c15b361938bea5976c846c147ecdc1121c0
Platform Version: 32.0a2
Firmware Version: P821A10v1.0.0806_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Buri 2.0 
Build ID: 20140616063005
Gecko: https://hg.mozilla.org/releases/mozilla-aurora/rev/f2413cf1965e
Gaia: a6988c15b361938bea5976c846c147ecdc1121c0
Platform Version: 32.0a2
Firmware Version: V1.2-device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Flame 1.4 
Build ID: 20140616000202
Gecko: https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/2949e8bef869
Gaia: 164644d91290708a71436dfdf4301e33b92e2c77
Platform Version: 30.0
Firmware Version: v121-2
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Comment 2

[Chris Kreinbring [:CKreinbring]]

Also repros on Buri 2.1 mozilla RIL

Build ID: 20140615103005
Gecko: https://hg.mozilla.org/mozilla-central/rev/80431d4fd0da
Gaia: dfc4703bb81d1fa4f2087a1a6124b47a80a5d1de
Platform Version: 33.0a1
Firmware Version: V1.2-device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Comment 3

[Jason Smith [:jsmith]]

This is bad. Really bad. Phone calls should always be the top priority.

Comment 4

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

Please separate the environmental variables next time for which devices and branches the issue reproduces on and which ones it does not. Also, make sure you include the actual result when trying to reproduce the issue. Also, Open C should have been checked on 2.1.

Comment 5

[Chris Kreinbring [:CKreinbring]]

Able to repro on Open C 2.1

Build ID: 20140616040202
Gecko: https://hg.mozilla.org/mozilla-central/rev/80431d4fd0da
Gaia: dfc4703bb81d1fa4f2087a1a6124b47a80a5d1de
Platform Version: 33.0a1
Firmware Version: P821A10v1.0.0806_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Comment 6

[Chris Kreinbring [:CKreinbring]]

On all devices that repro, the alarm page appears while in the middle of a call and while a call is incoming (when the user has neither answered nor rejected the call).

Comment 7

[Jason Smith [:jsmith]]

No window on the bug yet, so this isn't finished for QAnalyst triage

Comment 8

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

B2g-inbound Regression Window

Last working
Environmental Variables:
Device: Flame
BuildID: 20140606061657
Gaia: 3b43bc39a5d3b3a078774c72d8f772617a481835
Gecko: 43f8349a1140
Version: 32.0a1

First Broken
Environmental Variables:
Device: Flame
BuildID: 20140606065657
Gaia: 487af01e7a373b77da231dcf5e96c59efa5f1904
Gecko: 583fafa30638
Version: 32.0a1

Last working gaia / First broken gecko - Issue does NOT occur
Gaia: 3b43bc39a5d3b3a078774c72d8f772617a481835
Gecko: 583fafa30638

First broken gaia / Last working gecko - Issue DOES occur
Gaia: 487af01e7a373b77da231dcf5e96c59efa5f1904
Gecko: 43f8349a1140

Gaia Pushlog:  https://github.com/mozilla-b2g/gaia/compare/3b43bc39a5d3b3a078774c72d8f772617a481835...487af01e7a373b77da231dcf5e96c59efa5f1904

Comment 9

[Jason Smith [:jsmith]]

Broken by bug 988212.

Comment 10

[(inactive after 6/18) Alive Kuo [:alive]]

Yet another bug 988212 regression.

Comment 11

[(inactive after 6/18) Alive Kuo [:alive]]

Deassign since I am out next week. Will get back if nobody takes.

Comment 12

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

Vivien, do you have cycles to work on this regression?

Comment 13

[:shell escalante]

Hi Alive,  No one has picked up this bug yet - do you still have potential to take it if Vivien cannot?

Comment 14

[(Inactive after June) George Duan [:gduan] [:喬智]]

take it.

Comment 15

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Jason Smith [:jsmith] from comment #3)
> This is bad. Really bad. Phone calls should always be the top priority.

This has been changed voluntarily in bug 988212. The last attention screen wins.

If the phone is next to your ears, then the screen should be turned off and the alarm will not ring.
If the phone is not next to your ears, on a table for example, the the alarm comes in and the sound is merged with the phone call.

At least on my side it was expected because of the multiple possible attention screens. So removing the blocking flag, until UX confirms that it is not expected, and how we should deal with attention screen from webRTC apps...

Comment 16

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

Needinfo UX to confirm the above behavior change. This should be INVALID if we want to keep the current behavior.

Comment 17

[Jason Smith [:jsmith]]

(In reply to Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please) from comment #15)
> (In reply to Jason Smith [:jsmith] from comment #3)
> > This is bad. Really bad. Phone calls should always be the top priority.
> 
> This has been changed voluntarily in bug 988212. The last attention screen
> wins.
> 
> If the phone is next to your ears, then the screen should be turned off and
> the alarm will not ring.
> If the phone is not next to your ears, on a table for example, the the alarm
> comes in and the sound is merged with the phone call.

That sounds incorrect. Users won't always have their phone to their ears - take speaker mode for example, where someone would put the phone on a table when communicating with the other person.

> 
> At least on my side it was expected because of the multiple possible
> attention screens. So removing the blocking flag, until UX confirms that it
> is not expected, and how we should deal with attention screen from webRTC
> apps...

This is a poor user experience for anyone using speaker mode, so I tend to think the behavior here right now is incorrect.

Comment 18

[Jason Smith [:jsmith]]

There's a lot of debate on the behavior here. Two things we need here for a decision:

1. QA Wanted - Can we a get a video with sound?
2. Needinfo to Product (Comms + Productivity) to weigh in on what the right behavior here is.

Comment 19

[Jason Smith [:jsmith]]

I've also leaving needinfo here on Beatriz to figure out if there's a certification implication here if we change the behavior to what's seen in this bug.

Comment 20

[Stephany Wilkes]

It is difficult to discern what the UX question is here, and whether or not it's specific to Loop, as some comments seem to imply.

If I go with the original description vs. various comments, the question seems to be: Is the expected behavior that the call continues with no alarm reaction from the device? I believe the answer is yes: no one needs to hear an alarm during a call. Flagging Juwei to confirm.

Comment 21

[Jason Smith [:jsmith]]

(In reply to Stephany Wilkes from comment #20)
> It is difficult to discern what the UX question is here, and whether or not
> it's specific to Loop, as some comments seem to imply.

UX question is looking to understand what the expected behavior here is. It isn't specific to Loop - this is a regression against the Dialer that came from a Loop feature landing.

> 
> If I go with the original description vs. various comments, the question
> seems to be: Is the expected behavior that the call continues with no alarm
> reaction from the device? I believe the answer is yes: no one needs to hear
> an alarm during a call. Flagging Juwei to confirm.

Right - that's what the bug was filed about.

Comment 22

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

We cannot have it both ways -- accompany Loop and keep the Clock behavior at the same time -- if that what UX wants I think engineering should reject any poorly-thought spec change next time, instead of dancing around between these blocking bugs.

Comment 23

[Juwei Huang[:juwei]]

As far as I know, there's a meta bug tracking all the conflict condition of sound : Bug 991026 . I believe Jenny (Setting's ux owner) will deliver spec later base on this meta bug. 


And I also agree that the alarm should not go off when people are under a call. Yet I'm afraid if we auto-dismiss the alarm during the call, users might think their alarm has never went off.

So my suggestion would be making the vibration rather than sound if the alarm goes off during the call, then it would be somehow less harmful for users' ears but also notice users that the alarm goes off.

Here's the expecting flow:

1. Making/Answering a call

2. Alarm is on during the call. The alarm sound is mute, but vibration is on. The alarm UI shows on top of the call view.
** No matter the vibration of the alarm is set as on or off, the alarm will vibrate.
** The screen will light on again during the call when the alarm is on.

3. Tap on dismiss/snooze to get rid of the alarm view and back to call view


If there's any concern, let me know :)

Comment 24

[Jason Smith [:jsmith]]

So comment 23 implies there's a bug here, except only with the fact that the alarm is audible. Going to remove qawanted cause I missed the comment in comment 0 originally indicated that there was sound. I'll remove needinfo on product cause I agree with UX's assessment above in comment 23, so I don't think we need additional input (although Adam can feel free to weigh in with additional input if he desires to). I'll still wait for Beatriz's input to see if there's certification implications here.

Comment 25

[Beatriz Rodríguez [:brg]]

If voice call won't be mixed with any sound, the behaviour described in comment 23 seems ok for certification. Thanks for asking.

Comment 26

[Maire Reavy [:mreavy]]

Hi George -- Just to confirm: Will you be implementing the behavior in Comment 23 for this sprint (S5)?  Thanks.

Comment 27

[(Inactive after June) George Duan [:gduan] [:喬智]]

Attachment: PR to master

Based on comment 23, I think it should be implemented in clock app.

waiting for test result.

Comment 28

[(Inactive after June) George Duan [:gduan] [:喬智]]

Comment on attachment 8449884 [details] [review]
PR to master

Hi Marcus,
could you check this patch if there's any side effect?
We'd like alarm to be silent by still vibrate while on call no matter it's originally set off or on.

Thanks.

Comment 29

[Jason Smith [:jsmith]]

(In reply to George Duan [:gduan] [:喬智] from comment #28)
> Comment on attachment 8449884 [details] [review]
> PR to master
> 
> Hi Marcus,
> could you check this patch if there's any side effect?
> We'd like alarm to be silent by still vibrate while on call no matter it's
> originally set off or on.
> 
> Thanks.

Wouldn't the right fix here be done in gecko? Couldn't we still reproduce this bug by using a privileged app that does the same behavior as the clock here?

Comment 30

[(Inactive after June) George Duan [:gduan] [:喬智]]

Comment on attachment 8449884 [details] [review]
PR to master

remove review flag.

Comment 31

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Jason Smith [:jsmith] from comment #29)
> (In reply to George Duan [:gduan] [:喬智] from comment #28)
> > Comment on attachment 8449884 [details] [review]
> > PR to master
> > 
> > Hi Marcus,
> > could you check this patch if there's any side effect?
> > We'd like alarm to be silent by still vibrate while on call no matter it's
> > originally set off or on.
> > 
> > Thanks.
> 
> Wouldn't the right fix here be done in gecko? Couldn't we still reproduce
> this bug by using a privileged app that does the same behavior as the clock
> here?

Moved to audio channel component.
There's a policy about always playing sound for foreground app.
Since alarm becomes foreground after bug 988212, we need to fix the policy from gecko side.

Comment 32

[Maire Reavy [:mreavy]]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #31)
> 
> Moved to audio channel component.
> There's a policy about always playing sound for foreground app.
> Since alarm becomes foreground after bug 988212, we need to fix the policy
> from gecko side.
> Component: Gaia::Clock → AudioChannel
> Assignee: [e-mail] → [e-mail]

This bug is now a gecko bug?  That's a big change. 

We need to find a new owner for this ASAP.  Who can own this -- or who can help find a new owner? 

I wonder if it would make more sense (be less confusing) to create a new bug for the policy change on the gecko side?  If we decide to do that, please put "ft:loop" in the whiteboard of any new bug that Loop mobile depends on in v2.0.  Thanks.

Comment 33

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Maire Reavy [:mreavy] (Plz needinfo me) from comment #32)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #31)
> > 
> > Moved to audio channel component.
> > There's a policy about always playing sound for foreground app.
> > Since alarm becomes foreground after bug 988212, we need to fix the policy
> > from gecko side.
> > Component: Gaia::Clock → AudioChannel
> > Assignee: [e-mail] → [e-mail]
> 
> This bug is now a gecko bug?  That's a big change.

According to bug 988912 this is one of the missing part it doesn't take into account.
Bug 988912 was a big change already.

> 
> We need to find a new owner for this ASAP.  Who can own this -- or who can
> help find a new owner? 
> 
> I wonder if it would make more sense (be less confusing) to create a new bug
> for the policy change on the gecko side?  If we decide to do that, please
> put "ft:loop" in the whiteboard of any new bug that Loop mobile depends on
> in v2.0.  Thanks.

I will needinfo Star who had been working on audio channel, but it's up to him to take or not.

Comment 34

[Ivan Tsay (:ITsay)]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #31)
> (In reply to Jason Smith [:jsmith] from comment #29)
> > (In reply to George Duan [:gduan] [:喬智] from comment #28)
> > > Comment on attachment 8449884 [details] [review]
> > > PR to master
> > > 
> > > Hi Marcus,
> > > could you check this patch if there's any side effect?
> > > We'd like alarm to be silent by still vibrate while on call no matter it's
> > > originally set off or on.
> > > 
> > > Thanks.
> > 
> > Wouldn't the right fix here be done in gecko? Couldn't we still reproduce
> > this bug by using a privileged app that does the same behavior as the clock
> > here?
> 
> Moved to audio channel component.
> There's a policy about always playing sound for foreground app.
> Since alarm becomes foreground after bug 988212, we need to fix the policy
> from gecko side.

Per discussion with engineer, if we want to fulfill the UX specification in comment 23 with the gecko change, it seems the feasible way is to monitor the telephony/webRTC call and mute the other audio triggered by another foreground app. It looks to me the special case will be implemented in current audio channel service rule. Frankly speaking, I personally don't think it is right to workaround it in audio channel service this way.

There is undergoing discussion about the re-architecture of audio competing management by moving the audio channel management to gaia system app. I think the right solution should be considered in that re-architecture.

Star,

Mind if you can also take a look this and provide your comments from audio channel perspective. Thank you,

Comment 35

[u459114]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #31)
> Moved to audio channel component.
> There's a policy about always playing sound for foreground app.
> Since alarm becomes foreground after bug 988212, we need to fix the policy
> from gecko side.

https://wiki.mozilla.org/WebAPI/AudioChannels#Audio_Competing_Policy
Foreground app will never by suppressed according to current policy design.

How about only change alarm foreground policies from "Play" to "[1]
AudioChannelType  Priority   Foreground 
alarm 	          3          [1]   
[1] If there is any higher priority channel in playing then muted or paused. 

I think no one will intentionally launch an alarm app on call, so it's pretty safe to do that.

Comment 36

[Star Cheng [:scheng]]

I flashed the nexus-4 device with the newest SW code[1]. I update the scenarios as followings:

a) Launch the Clock app and set an alarm.
b) Make a call to nexus-4 device and pick up the call.
c) While alarm is launched and observe the screen when the time comes.

1.If the phone is next to your ears:
 - 1.1)There is "du du" sound instead of alarm alter tone to remind user.
 - 1.2)There is vibration to remind user.
 - 1.3)If you remove the device from your ears and then turn it back near your ears, there is no vibration and "du du" sound. And remove it from your ears again, the device is vibrating and making "du du" sound again.

2.If the phone is *not* next to your ears:
 - 2.1)There is "du du" sound instead of alarm alter tone to remind user.
 - 2.2)There is vibration to remind user.
 - 2.3)The screen shows alarm is ringing.


It should be enough to remind user alarm is launching while in call according to above 2 behaviors. And there is the same behavior for the Android phone [2] except the item 1.3). I thinks is is *not* a blocked issue.


[1] SW code info
device     Nexus-4
Gaia      1dc9e53393ae4680a174dffa44a958ec564ebbe8
Gecko     https://hg.mozilla.org/mozilla-central/rev/dfef245594b6
BuildID   20140707160202
Version   33.0a1
ro.build.version.incremental=eng.cltbld.20140707.190948
ro.build.date=Mon Jul  7 19:09:58 EDT 2014

[2] HTC new one

Comment 37

[Jason Smith [:jsmith]]

comment 36 is irrelevant data here. Different vendors have different certification requirements to allow a device to be certified in target markets. It doesn't matter if Android does right now if our target vendors have already indicated that the *current* behavior will not pass certification. Putting the blocking flag back as the requirements for comment 25 *must* be met to allow our device to pass certification.

Comment 38

[Maire Reavy [:mreavy]]

Star -- Since this is a *must* for v2.0 (see comment 37), can you own this bug or find an owner for it today?

Comment 39

[Juwei Huang[:juwei]]

After further discuss with Jenny, Star, CJ & Alive, I changed some of the behaviours on comment 23. Here's the expecting experience: 

- In 2.0 - 

Due to time limitation and resource constraint, I think it's acceptable to close the behaviour to what we have now. I've tested it on my flame and there's no loud beeping but a low "du du" sound in the background. Based on the behaviour now, my suggestion would be:

Scenario 1: When an alarm activates on the time while users under a call and hold their phone besides ear (screen is off) , the screen will on and show the alarm view with a "du du" sound in the background.
** The device still maintains the alarm screen & sound if users take the phone down.

Scenario 2: When an alarm activates on the time while users under a call and place their phone on a desk (screen is on), the screen will show the alarm view with a "du du" sound in the background.
** The device still maintains the alarm screen & sound if users put the phone besides ear.

Right now the behaviour on flame is slightly different from what I describe above: In scenario 1, the alarm is in the background rather then foreground. 
I think it's more reasonable to keep both scenario 1& 2 the same so that we can create an consistency behaviour across different situations.


- In 2.1 -

I think we can make the alarm sound in a low voice (20%) when under telephony, so both scenario 1 & 2 will show alarm screen with a low voice alarm sound.
** The vibration will depend on the original settings.


Let me know your thought, thanks.

Comment 40

[Star Cheng [:scheng]]

(In reply to Maire Reavy [:mreavy] (Plz needinfo me) from comment #38)
> Star -- Since this is a *must* for v2.0 (see comment 37), can you own this
> bug or find an owner for it today?


The "du du" sound is made by AOSP HAL[1]. The code is *not* in Gecko, and I think our partner is a better candidate to modify it. IMO Mozilla want to cook a "general" mobile operating system instead of "specific" one. So I don't think we must modify the behaviors of FFOS for fit any operator requirement or certification. 



[1]http://androidxref.com/4.4.3_r1.1/xref/hardware/libhardware_legacy/audio/AudioPolicyManagerBase.cpp#3218

Comment 41

[(inactive after 6/18) Alive Kuo [:alive]]

I had found why flame had unexpected behavior:
https://github.com/alivedise/gaia/blob/3774ec274e404e59f7ebf670215ea8151b0d4b3f/apps/system/js/screen_manager.js#L242
There is a callschanged event to tell system to bring callscreen on top when alarm turns on the screen while in a call with p-sensor on. This event is only observed on flame but not other device(nexus4).

Of course we should not have any callschanged event because there's no 2nd call while alarm is ringing.

But this explains why people see different behavior:
Why sometimes alarm is foreground somes it's background.

Comment 42

[Jason Smith [:jsmith]]

Leaving qawanted here to get a video with sound.

Comment 43

[Beatriz Rodríguez [:brg]]

I have tried to repro but no luck... I will try again tomorrow. 

However, could you please explain the behaviour of devices without proximity sensor(like Open C and Open II that automatically turn off the display after few seconds to avoid waste of battery even with the speaker activated)? I do not even know if there is a difference in the behaviour, I just want to understand it and check if you cover in your use cases or maybe we should not care because this is part of vendor work.

Comment 44

[Star Cheng [:scheng]]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #41)
> I had found why flame had unexpected behavior:
> https://github.com/alivedise/gaia/blob/
> 3774ec274e404e59f7ebf670215ea8151b0d4b3f/apps/system/js/screen_manager.
> js#L242
> There is a callschanged event to tell system to bring callscreen on top when
> alarm turns on the screen while in a call with p-sensor on. This event is
> only observed on flame but not other device(nexus4).
> 
> Of course we should not have any callschanged event because there's no 2nd
> call while alarm is ringing.
> 
> But this explains why people see different behavior:
> Why sometimes alarm is foreground somes it's background.

Thanks for Alive's analysis. I have tried the behavior in OpenC device as well, and it's behavior is the same as nexux-4 device. And Aknow is analyzing the callschanged event.

Comment 45

[Szu-Yu Chen [:aknow] (inactive)]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #41)
> I had found why flame had unexpected behavior:
> https://github.com/alivedise/gaia/blob/
> 3774ec274e404e59f7ebf670215ea8151b0d4b3f/apps/system/js/screen_manager.
> js#L242
> There is a callschanged event to tell system to bring callscreen on top when
> alarm turns on the screen while in a call with p-sensor on. This event is
> only observed on flame but not other device(nexus4).
> 
> Of course we should not have any callschanged event because there's no 2nd
> call while alarm is ringing.
> 
> But this explains why people see different behavior:
> Why sometimes alarm is foreground somes it's background.

In current telephony design, if someone adds a new listener to 'callschanged' event, this event will be fired immediately even there is no calls changes. The behaviour is used to indicate the telephony object is ready to use....

=> Well, it's not a good idea (the meaning is not clear). So we're going to use another way to convey the 'ready' information. After that, there should be no extra 'callschanged' event in this scenario and we could resolve the problem.

However, I don't know why is there no 'callschanged' event on nexus-4 device.

Comment 46

[Juwei Huang[:juwei]]

Hi Beatriz, 
The behaviour should be the same if the display turns off automatically. You can refer to bug 996092.
I think in this case, telephony screen is always activated even when the screen is dark so the alarm will keep going off until users hang off the phone and the screen falls asleep.

Comment 47

[Chris Kreinbring [:CKreinbring]]

YouTube clip has been added with sound.  The bug seems to have changed slightly, as the alarm sound is no longer heard when the alarm goes off in the middle of a call.

Tested on the latest Flame 2.0 since the latest Flame 2.1 was unable to be tested due to bug 1037079.

Build ID: 20140711000201
Gaia: 18c44a1bc31b374ba00a069904465a8d07971a60
Gecko: f880dae4fdbe
Platform Version: 32.0a2
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 48

[Jason Smith [:jsmith]]

(In reply to Chris Kreinbring [:CKreinbring] from comment #47)
> YouTube clip has been added with sound.  The bug seems to have changed
> slightly, as the alarm sound is no longer heard when the alarm goes off in
> the middle of a call.
> 
> Tested on the latest Flame 2.0 since the latest Flame 2.1 was unable to be
> tested due to bug 1037079.
> 
> Build ID: 20140711000201
> Gaia: 18c44a1bc31b374ba00a069904465a8d07971a60
> Gecko: f880dae4fdbe
> Platform Version: 32.0a2
> Firmware Version: v122
> User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

The behavior seen in the video here right now actually looks fine to me.

Beatriz - What do you think?

Comment 49

[:shell escalante]

Can we get a video from the scenario that was broken on the Flame, described in comment 39?  The key is when the user is on a call and the screen is OFF - the Alarm does not come to the forefront to be addressed.

Scenario 1: When an alarm activates on the time while users under a call and hold their phone besides ear (screen is off) , the screen will on and show the alarm view with a "du du" sound in the background.
** The device still maintains the alarm screen & sound if users take the phone down.

Right now the behaviour on flame is slightly different from what I describe above: In scenario 1, the alarm is in the background rather then foreground. 
I think it's more reasonable to keep both scenario 1& 2 the same so that we can create an consistency behaviour across different situations.

Comment 50

[:shell escalante]

Also - when doing the video - is this behavior just for if it's a Loop calling coming in during and existing call and the screen is BLANK, or also when a regular call comes in as well.

Comment 51

[Joshua Mitchell (Inactive)]

Qa-Wanted for the video (comment 49 and 50)

Comment 52

[Chris Kreinbring [:CKreinbring]]

Video clip created using the latest Flame 2.0

http://youtu.be/npfhqkn_VoI

Build ID: 20140714000202
Gaia: ca022f811bcbbda0f89086094a9e92bb220fea18
Gecko: 376889ab0e02
Platform Version: 32.0a2
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 53

[Maire Reavy [:mreavy]]

From an email thread this morning about this bug:

It doesn't look like the scenario in the video on the bug (1026167) is the one described as broken (it's confusing as there was a lot of comments in this bug).

The difference is when the user is on a call and the screen is OFF - the Alarm does not come to the forefront to be addressed. If this is an edge case with Loop calls on Flame, at this point - maybe we can live with hanging up to end the alarm. But i think it's a regular call being tested for interruption behavior with alarm on, and i'm not sure on the tolerance for that.

Desired Scenario 1: When an alarm activates on the time while users under a call and hold their phone besides ear (screen is off) , the screen will on and show the alarm view with a "du du" sound in the background.

Current Scenario 1: Right now the behavior on flame, the alarm is in the background rather then foreground - so the user has to end the call to get to the Alarm screen on Flame.

-----------------

I don't see this as a blocker for Loop.  Most Loop calls will not be next to the ear because the user will be looking at the remote video and the screen will be on.  However, I don't know what the behavior is for telephony calls and the clock alarm.

Star, Alive -- This bug is currently a v2.0 blocker; we're looking at videos of the scenario to see if it truly is a blocker or not.  If it remains a blocker (which we'll decide today), we may need a developer to change the current scenario ASAP.  Can you help find a developer for this today in case work is needed?  Thank you.

Comment 54

[Maire Reavy [:mreavy]]

(In reply to Chris Kreinbring [:CKreinbring] from comment #52)
> Video clip created using the latest Flame 2.0
> 
> http://youtu.be/npfhqkn_VoI
> 
> Build ID: 20140714000202
> Gaia: ca022f811bcbbda0f89086094a9e92bb220fea18
> Gecko: 376889ab0e02
> Platform Version: 32.0a2
> Firmware Version: v122
> User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Chris -- Thanks for the video clip.  That looked to be a Loop call.  What about typical cell phone telephony calls?  Do have the same issue?  (i.e. Do you have to end the call to dismiss the alarm?)

Comment 55

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Szu-Yu Chen [:aknow] from comment #45)
> (In reply to Alive Kuo [:alive][NEEDINFO!] from comment #41)
> > I had found why flame had unexpected behavior:
> > https://github.com/alivedise/gaia/blob/
> > 3774ec274e404e59f7ebf670215ea8151b0d4b3f/apps/system/js/screen_manager.
> > js#L242
> > There is a callschanged event to tell system to bring callscreen on top when
> > alarm turns on the screen while in a call with p-sensor on. This event is
> > only observed on flame but not other device(nexus4).
> > 
> > Of course we should not have any callschanged event because there's no 2nd
> > call while alarm is ringing.
> > 
> > But this explains why people see different behavior:
> > Why sometimes alarm is foreground somes it's background.
> 
> In current telephony design, if someone adds a new listener to
> 'callschanged' event, this event will be fired immediately even there is no
> calls changes. The behaviour is used to indicate the telephony object is
> ready to use....
> 
> => Well, it's not a good idea (the meaning is not clear). So we're going to
> use another way to convey the 'ready' information. After that, there should
> be no extra 'callschanged' event in this scenario and we could resolve the
> problem.
> 
> However, I don't know why is there no 'callschanged' event on nexus-4 device.

But in screen_manager.js we only attach the callschanged once.
https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/screen_manager.js#L172

While in a call it's impossible to trigger ScreenManager.init()(who adds the event listener) to be called again.

The analysis doesn't seem correct to me.

Comment 56

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Maire Reavy [:mreavy] (Plz needinfo me) from comment #53)
> From an email thread this morning about this bug:
> 
> It doesn't look like the scenario in the video on the bug (1026167) is the
> one described as broken (it's confusing as there was a lot of comments in
> this bug).
> 
> The difference is when the user is on a call and the screen is OFF - the
> Alarm does not come to the forefront to be addressed. If this is an edge
> case with Loop calls on Flame, at this point - maybe we can live with
> hanging up to end the alarm. But i think it's a regular call being tested
> for interruption behavior with alarm on, and i'm not sure on the tolerance
> for that.
> 
> Desired Scenario 1: When an alarm activates on the time while users under a
> call and hold their phone besides ear (screen is off) , the screen will on
> and show the alarm view with a "du du" sound in the background.
> 
> Current Scenario 1: Right now the behavior on flame, the alarm is in the
> background rather then foreground - so the user has to end the call to get
> to the Alarm screen on Flame.
> 
> -----------------
> 
> I don't see this as a blocker for Loop.  Most Loop calls will not be next to
> the ear because the user will be looking at the remote video and the screen
> will be on.  However, I don't know what the behavior is for telephony calls
> and the clock alarm.
> 
> Star, Alive -- This bug is currently a v2.0 blocker; we're looking at videos
> of the scenario to see if it truly is a blocker or not.  If it remains a
> blocker (which we'll decide today), we may need a developer to change the
> current scenario ASAP.  Can you help find a developer for this today in case
> work is needed?  Thank you.

The root cause of different behavior on different device is still unknown - comment 45 doesn't convince me.
If we think the later alarm should appear the old callscreen and we think it's blocker, please open another bug and nominate.
It's the behavior we found during investigating this bug, but "this bug" should be not blocking according to lots of comments above and UX had confirmed nothing need to do within v2.0.

Comment 57

[Joshua Mitchell (Inactive)]

> Chris -- Thanks for the video clip.  That looked to be a Loop call.  What
> about typical cell phone telephony calls?  Do have the same issue?  (i.e. Do
> you have to end the call to dismiss the alarm?)


Hi Marie - we can't come to a consensus on what you mean by 'loop call' - this call was made from 1 mobile device to another mobile device (both Flame devices). Hope that helps

Comment 58

[Joshua Mitchell (Inactive)]

AND... sorry for misspelling your name 

Maire not Marie... I blame mondays?

Comment 59

[Maire Reavy [:mreavy]]

(In reply to Joshua Mitchell [:Joshua_M] from comment #57)
> > Chris -- Thanks for the video clip.  That looked to be a Loop call.  What
> > about typical cell phone telephony calls?  Do have the same issue?  (i.e. Do
> > you have to end the call to dismiss the alarm?)
> 
> 
> Hi Marie - we can't come to a consensus on what you mean by 'loop call' -
> this call was made from 1 mobile device to another mobile device (both Flame
> devices). Hope that helps

I was wondering if you were using the Loop mobile app to make the call in your last video or if you were using the default dialer.  It sounds like you were using the default dialer, and that the last video was showing a regular, telephony call (not a call made with the mobile Loop app).  Is that correct?

Comment 60

[Maire Reavy [:mreavy]]

Tony -- Per Alive's comments above (Comment 56), can this bug be removed as a blocker for v2.0?  And do you want to file a new bug or is that not needed?  For my use cases, this is not a Loop blocker for v2.0.

Comment 61

[Joshua Mitchell (Inactive)]

> I was wondering if you were using the Loop mobile app to make the call in
> your last video or if you were using the default dialer.  It sounds like you
> were using the default dialer, and that the last video was showing a
> regular, telephony call (not a call made with the mobile Loop app).  Is that
> correct?

Yes, that is correct. We did NOT use a mobile loop app.  This was a regular telephony call with the default dialer.

Comment 62

[Tony Chung [:tchung]]

(In reply to Alive Kuo [:alive][NEEDINFO!][Berlin 7/14-7/18] from comment #56)

> The root cause of different behavior on different device is still unknown -
> comment 45 doesn't convince me.
> If we think the later alarm should appear the old callscreen and we think
> it's blocker, please open another bug and nominate.
> It's the behavior we found during investigating this bug, but "this bug"
> should be not blocking according to lots of comments above and UX had
> confirmed nothing need to do within v2.0.

i'm going to move this back to 2.0? nom, since it sounds a lot like feature work in order to get this done right.  This is reproducible on other devices too, so its not just flame based.  It's also recoverable by the user when the alarm goes off, but just hitting the stop button.   This also isnt a loop-only issue, so i'll move this bug back to system: windows management.   

If anyone else disagrees, please renominate the bug for 2.0, but given this really is not a common scenario and is recoverable, lets focus on other critical 2.0+ bugs in the time remaining.

Personally, i would suggest backlogging this bug and fixed in the next release.

Comment 63

[Tony Chung [:tchung]]

moving to gaia:system: window management.  if this is mostly gecko work, please reassign.  thanks.

Comment 64

[(inactive after 6/18) Alive Kuo [:alive]]

Moving to AudioChannel. Mute Alarm while telephony/VOIP is running is not gaia work now.

Comment 65

[Maire Reavy [:mreavy]]

removing from Loop watch list

Comment 66

[Jason Smith [:jsmith]]

(In reply to Chris Kreinbring [:CKreinbring] from comment #52)
> Video clip created using the latest Flame 2.0
> 
> http://youtu.be/npfhqkn_VoI
> 
> Build ID: 20140714000202
> Gaia: ca022f811bcbbda0f89086094a9e92bb220fea18
> Gecko: 376889ab0e02
> Platform Version: 32.0a2
> Firmware Version: v122
> User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

The video here doesn't have sound. Please repost a video with sound.

Comment 67

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] - PTO 7/14 - 7/18 from comment #66)
> (In reply to Chris Kreinbring [:CKreinbring] from comment #52)
> > Video clip created using the latest Flame 2.0
> > 
> > http://youtu.be/npfhqkn_VoI
> > 
> > Build ID: 20140714000202
> > Gaia: ca022f811bcbbda0f89086094a9e92bb220fea18
> > Gecko: 376889ab0e02
> > Platform Version: 32.0a2
> > Firmware Version: v122
> > User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
> 
> The video here doesn't have sound. Please repost a video with sound.

Actually wait a second. The entire analysis that happened in the latter half of the comments is entirely incorrect here. This is *not* what the reporter filed the bug about. The latest video has nothing to do with the bug here, as the original STR indicated nothing about putting the phone to sleep.

First, resetting flags here since I think engineering went off topic in the bug & confused what the scope of the bug was targeting. Second, re-adding qawanted to re-indicate the STR that the bug was *originally* filed against.

Comment 68

[Jason Smith [:jsmith]]

(In reply to Tony Chung [:tchung] from comment #62)
> (In reply to Alive Kuo [:alive][NEEDINFO!][Berlin 7/14-7/18] from comment
> #56)
> 
> > The root cause of different behavior on different device is still unknown -
> > comment 45 doesn't convince me.
> > If we think the later alarm should appear the old callscreen and we think
> > it's blocker, please open another bug and nominate.
> > It's the behavior we found during investigating this bug, but "this bug"
> > should be not blocking according to lots of comments above and UX had
> > confirmed nothing need to do within v2.0.
> 
> i'm going to move this back to 2.0? nom, since it sounds a lot like feature
> work in order to get this done right.  This is reproducible on other devices
> too, so its not just flame based.  It's also recoverable by the user when
> the alarm goes off, but just hitting the stop button.   This also isnt a
> loop-only issue, so i'll move this bug back to system: windows management. 

Most of this information is not correct. This was considered a fallout from introducing multiple attention screens, so this was a regression as filed against what the reporter originally filed. The recovery path isn't relevant because the original blocking concern was about the sound interrupting the call, not the fact that the stop button was present. 
  
> 
> If anyone else disagrees, please renominate the bug for 2.0, but given this
> really is not a common scenario and is recoverable, lets focus on other
> critical 2.0+ bugs in the time remaining.

I think you've misinterpreted the bug heavily here. Please discuss with Chris to understand what was originally reported here & keep the scope of the bug focused on that problem solely. Our partner also needs to signoff on the behavior, which I don't see written down here.

Comment 69

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] - PTO 7/14 - 7/18 from comment #66)
> (In reply to Chris Kreinbring [:CKreinbring] from comment #52)
> > Video clip created using the latest Flame 2.0
> > 
> > http://youtu.be/npfhqkn_VoI
> > 
> > Build ID: 20140714000202
> > Gaia: ca022f811bcbbda0f89086094a9e92bb220fea18
> > Gecko: 376889ab0e02
> > Platform Version: 32.0a2
> > Firmware Version: v122
> > User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
> 
> The video here doesn't have sound. Please repost a video with sound.

Actually disregard the qawanted request here. I'd like to see an indication a reposting of the STR that was originally used to reproduce the bug, the current behavior exhibited, and the actual behavior seen. I'd like to make sure we understand what in and out of scope of the bug here.

Comment 70

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] - PTO 7/14 - 7/18 from comment #69)
> (In reply to Jason Smith [:jsmith] - PTO 7/14 - 7/18 from comment #66)
> > (In reply to Chris Kreinbring [:CKreinbring] from comment #52)
> > > Video clip created using the latest Flame 2.0
> > > 
> > > http://youtu.be/npfhqkn_VoI
> > > 
> > > Build ID: 20140714000202
> > > Gaia: ca022f811bcbbda0f89086094a9e92bb220fea18
> > > Gecko: 376889ab0e02
> > > Platform Version: 32.0a2
> > > Firmware Version: v122
> > > User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
> > 
> > The video here doesn't have sound. Please repost a video with sound.
> 
> Actually disregard the qawanted request here. I'd like to see an indication
> a reposting of the STR that was originally used to reproduce the bug, the
> current behavior exhibited, and the actual behavior seen. I'd like to make
> sure we understand what in and out of scope of the bug here.

The original STR note should include an indication of the placement of the phone as well.

Comment 71

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] - PTO 7/14 - 7/18 from comment #69)
> (In reply to Jason Smith [:jsmith] - PTO 7/14 - 7/18 from comment #66)
> > (In reply to Chris Kreinbring [:CKreinbring] from comment #52)
> > > Video clip created using the latest Flame 2.0
> > > 
> > > http://youtu.be/npfhqkn_VoI
> > > 
> > > Build ID: 20140714000202
> > > Gaia: ca022f811bcbbda0f89086094a9e92bb220fea18
> > > Gecko: 376889ab0e02
> > > Platform Version: 32.0a2
> > > Firmware Version: v122
> > > User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
> > 
> > The video here doesn't have sound. Please repost a video with sound.
> 
> Actually disregard the qawanted request here. I'd like to see an indication
> a reposting of the STR that was originally used to reproduce the bug, the
> current behavior exhibited, and the actual behavior seen. I'd like to make
> sure we understand what in and out of scope of the bug here.

That should say "current behavior exhibited, and the expected behavior here."

Comment 72

[Kai-Chih Hu [:khu]]

Eric, since this bug is tagged with AutdioChannel component, and you're the owner. Do you have any idea about this bug? Who could own this bug? Thank you!

Comment 73

[Eric Chou [:ericchou] [:echou]]

I agree with Jason about what he said in comment 69. Let's clarify what the actual problem is, what behaviour do we expect, and is this issue really needed to be a 2.0+ blocker.

========================

Let me try to summarize what we've got so far.

If we take a look at comment 0, the actual behaviour that reporter observed was:

  "The alarm page appears, the device vibrates if the option was enabled, and beeping can be heard from the device."

Also, Juwei has provided UX spec for FxOS 2.0 in comment 39 -- no matter the screen was off or on, when an alarm activates on the time while users under a call: 

  (1) the screen will show the alarm view
  (2) "du du" sound should be heard in the background.

So we've got the expected / actual behaviour, then what's the problem?

Star has tested by using Flame installed with the latest 2.0 build. I just confirmed with him that (1) and (2) were behave as expected when the device was on the table, however (A) the alarm window didn't show and (B) no beeping was heard when the device was close to your ears.

========================

To sum up, I suggest that:

1. Triagers should decide if this should be a blocker based on the incoming QA's analysis.
2. File two bugs for (A) and (B) since this one has too much information.
3. We should fix (A) then (B), which means "make Alarm app go foreground then see if (B) will still exist", because once (A) gets fixed then (B) may not happen.

Please correct me if anything described above is wrong. Thanks.

Comment 74

[Jason Smith [:jsmith]]

Thanks Eric for clarifying the scope of the bug here. I agree that we should split the bug out here, as I think there's too much scope confusion going on in the bug at this point. I'm closing this bug out & filed two new issues for [A] & [B] described above.

* [A] - bug 1038691
* [B] - bug 1038693

Comment 75

[Eric Chou [:ericchou] [:echou]]

(In reply to Jason Smith [:jsmith] - PTO 7/14 - 7/18 from comment #74)
> Thanks Eric for clarifying the scope of the bug here. I agree that we should
> split the bug out here, as I think there's too much scope confusion going on
> in the bug at this point. I'm closing this bug out & filed two new issues
> for [A] & [B] described above.
> 
> * [A] - bug 1038691
> * [B] - bug 1038693

Thanks for responding so quickly, Jason!

Comment 76

[Star Cheng [:scheng]]

(In reply to Jason Smith [:jsmith] - PTO 7/14 - 7/18 from comment #74)
> Thanks Eric for clarifying the scope of the bug here. I agree that we should
> split the bug out here, as I think there's too much scope confusion going on
> in the bug at this point. I'm closing this bug out & filed two new issues
> for [A] & [B] described above.
> 
> * [A] - bug 1038691
> * [B] - bug 1038693

Hi, Beatriz

How do we deal with the certification problem which mentioned in comment 25? Is there any concern about that?

Comment 77

[Beatriz Rodríguez [:brg]]

Thanks for asking and for the good summary (Eric). I do not see any blocker for certification. IMHO we should prioritize the resolution of those two bugs.

Comment 78

[John Thomas [:Johnt]]

This case IS still valid. Step 5 needs to be updated so that it mentions the phone will vibrate when the alarm is active during a phone call.

Comment 79

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

Test case has been updated in moztrap to state that there should be a low sound, screen on and vibration if enabled during a call: 

https://moztrap.mozilla.org/manage/case/4500/