Firefox OS v1.3 Mozilla build ID: 20140208004002 Created an attachment (id=648479) Screenshots for this PR DEFECT DESCRIPTION: MS can't make an emergency call when there are an active call and a held call. REPRODUCING PROCEDURES: 1. Idle -> Enter Phone App -> Make a call -> Tap "Add call" icon to make another call(The first call is held) -> Tap "Add call" icon to make an emergency call(112) -> MS can't make an emergency call (K.O.) EXPECTED BEHAVIOUR: MS should release of the active call and the call on hold then emergency call setting up. ASSOCIATE SPECIFICATION: TEST PLAN REFERENCE: TOOLS AND PLATFORMS USED: USER IMPACT: REPRODUCING RATE: 100% For FT PR, PleaseInsert list reference mobile's behavior:

The iphone behavier: 1.Dial a call -> Press "Add call" to dial emergence call -> The first call will be hung up and the emergency call dial out. 2.Dial a call -> Press "Add call" dial another call, and the first call will be on hold -> Can not dial the third call, because the "Add call" icon change to "Merge call" icon

1. Does this reproduce on a 1.1 Buri device?

In 1.1, cannot add a call while already in-call

Please follow the iphone's behavier in comment 2.Thanks a lot!

Emergency call is a priority.

I'll put this on in-moztrap backlog, but keeping unassigned for now until resources come free to work on this.

I don't think we can emulate iPhone behavior entirely for 1.3 as that would require some visual changes and I am also unsure that UX would be happy with it anyway, but we can certainly do better and at least do point 1 from comment 2.

clear ni?

How is that a 1.3+ blocker? The error message is very clear for the user.

(In reply to Anthony Ricaud (:rik) from comment #10) > How is that a 1.3+ blocker? The error message is very clear for the user. It was considered a certification blocker from TEF. Emergency calls apparently always have to work.

I'm not really sure we should make any decision for the user at that point. If they are on the phone with person A and B. B is in need of assistance so our user tries to call an emergency number. With this implemented, we might hang up the call with B where our user would have preferred dropping the call with A. Anyway, asking Carrie.

This is our suggestion of implementation in the two cases you mentioned in comment 2. 1.Dial a call -> Press "Add call" to dial emergence call -> Call to emergency call while the other call is on hold. After finished emergency call, resume the previuos call. Current behaviour in 1.3 -- > No changes needed here. 2.Dial a call -> Press "Add call" dial another call, and the first call will be on hold -> wait till the second call is answered --> Add a new call to dial emergency number --> press call, the previous two calls will be automatically hung up and the call to the emergency number will be done. Does this implementation fit your requirements?

(In reply to Beatriz Rodríguez [:brg] from comment #13) > 2.Dial a call -> Press "Add call" dial another call, and the first call will > be > on hold -> wait till the second call is answered --> Add a new call to dial > emergency number --> press call, the previous two calls will be > automatically hung up and the call to the emergency number will be done. > So we will allow the user to dial and show the error attached in comment 1 if the dialed number isn't an emergency one? That feels like an UX regression to me.

(In reply to Beatriz Rodríguez [:brg] from comment #13) > This is our suggestion of implementation in the two cases you mentioned in > comment 2. > 1.Dial a call -> Press "Add call" to dial emergence call -> Call to > emergency call while the other call is on hold. After finished emergency > call, resume the previuos call. Current behaviour in 1.3 -- > No changes > needed here. > > 2.Dial a call -> Press "Add call" dial another call, and the first call will > be > on hold -> wait till the second call is answered --> Add a new call to dial > emergency number --> press call, the previous two calls will be > automatically hung up and the call to the emergency number will be done. > > Does this implementation fit your requirements? Hi, we can accept this suggestion, but about the point 2, if the user dial a number is not an emergency one, it should show the error attachen in comment 1.

I agree with Beatriz on proposal 1. No need to hang up the first call when users dial emergency call as the second one (like what IPhone does now). However, when there are two calls connected (the first one is on hold), I'd suggest to pop up the confirm window (as the attached screenshot) when users tap the "Add call" button for the third call (no matter it's an emergency call or not). In this way, they can at least tap Cancel and go back directly to the multiple-calls page to decide to which one should be hung up and then make a new call. It will be quicker than popping up the confirm window after the numbers are already dialed. From UX perspective, I don't suggest automatically hang up a call for users, especially in emergency calls scenario. As Anthony's concern, we can't suspect which call is more important. So, the flow will be: 1.Dial a call -> Press "Add call" to dial -> Call to the second call while the other call is on hold. After finishing the second call, resume the previous call. 2.Dial a call -> Press "Add call" dial another call, and the first one will be on hold -> wait till the second call is answered --> Press the "Add call" button to dial the third number --> The confirm window pops up and tell users to hang up a call --> Tap Cancel and go back to the multiple calls page. Thanks!

Thanks Carrie! If I am not wrong, what you describe is the current behavior, so it seems that nothing needs to be done here. Maybe the confusion comes from the fact that the bug description is not accurate enough. > > REPRODUCING PROCEDURES: > 1. Idle -> Enter Phone App -> Make a call -> Tap "Add call" icon to make > another call(The first call is held) -> Tap "Add call" icon to make an > emergency call(112) -> MS can't make an emergency call (K.O.) "MS can't make an emergency call" is not correct. We can make an emergency call, we just need to hang up the previous active call. The message shown is clear about it: "Cannot make a call. If you are already dialing, please hang up first".

Fernando: Nope, it's not the current behaviour. Carrie's proposition would warn the user when they press the "Add call" icon on the call screen.

Oh right, that's true! I'll write a patch for what Carrie describes in Comment 16 then.

Great, so we all agree with current behaviour with scenario 1 in 1.3 Regarding scenario 2: Dear Mingming Zhao, We think that current implementation in v1.3 is good enough with current warn message in comment 1 to let users know that emergency calls are not available with two already established calls. However we are open to improve current implementation following Carrie specs in comment 16: > However, when there are two calls connected (the first one is on hold), I'd > suggest to pop up the confirm window (as the attached screenshot) when users > tap the "Add call" button for the third call (no matter it's an emergency > call or not). In this way, they can at least tap Cancel and go back directly > to the multiple-calls page to decide to which one should be hung up and then > make a new call. It will be quicker than popping up the confirm window after > the numbers are already dialed. > > So, the flow will be: > > 2.Dial a call -> Press "Add call" dial another call, and the first one will > be > on hold -> wait till the second call is answered --> Press the "Add call" > button to dial the third number --> The confirm window pops up and tell > users to hang up a call --> Tap Cancel and go back to the multiple calls > page. We think this is not a blocker for 1.3 but a nice improvement in future FxOS releases. Can we remove the blocking flag to this bug in 1.3?

Clearing blocking flag for comment 20 - renom if someone still feels this is a cert blocker.

Dears, we still think the Emergency call is a priority. In any cases, it should dial out success!

Adding to backlog to be properly prioritized. Thanks!

link all Fire C (codename: Sora) bugs to a meta one.

Firefox OS is not being worked on