977434 - [Sora][Call] [SOS] [CHW]MS can't make an emergency call when there are an active call and a held call.

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Dialer, defect, P1)

Description

[sync-1]

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:

Comment 1

[sync-1]

Attachment: Screenshots for this PR

Comment 2

[Mingming ZHAO]

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

Comment 3

[Jason Smith [:jsmith]]

1. Does this reproduce on a 1.1 Buri device?

Comment 4

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

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

Comment 5

[Mingming ZHAO]

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

Comment 6

[Preeti Raghunath(:Preeti)]

Emergency call is a priority.

Comment 7

[Jason Smith [:jsmith]]

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

Comment 8

[Fernando Jiménez Moreno [:ferjm]]

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.

Comment 9

[David Scravaglieri [:scravag]]

clear ni?

Comment 10

[Anthony Ricaud (:rik)]

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

Comment 11

[Jason Smith [:jsmith]]

(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.

Comment 12

[Anthony Ricaud (:rik)]

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.

Comment 13

[Beatriz Rodríguez [:brg]]

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?

Comment 14

[Fernando Jiménez Moreno [:ferjm]]

(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.

Comment 15

[Mingming ZHAO]

(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.

Comment 16

[Carrie Wang [New account: [e-mail]]]

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!

Comment 17

[Fernando Jiménez Moreno [:ferjm]]

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".

Comment 18

[Anthony Ricaud (:rik)]

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.

Comment 19

[Fernando Jiménez Moreno [:ferjm]]

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

Comment 20

[Beatriz Rodríguez [:brg]]

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?

Comment 21

[Jason Smith [:jsmith]]

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

Comment 22

[Mingming ZHAO]

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

Comment 23

[Noemí Freire (:noemi)]

Adding to backlog to be properly prioritized. Thanks!

Comment 24

[Wesly Huang (EPM)]

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

Comment 25

[BMO Automation]

Firefox OS is not being worked on