895226 - [Dialer] When holding call and receiving second call, cannot accept second call

Status: RESOLVED FIXED

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

Description

[Leo]

1. Title : When holding call and receiving second call, cannot accept second call
2. Precondition : Hold current call
3. Tester's Action : Receive second call
4. Detailed Symptom : Cannot accept second call. Only can ignore call
5. Expected : Can accept call
6. Reproducibility: Y
1) Frequency Rate : 100%
7. Gaia Master/v1-train : Reproduce
8. Gaia Revision : 0d5a9a7577f16b6a72a982148c6f509ee1714ea2
9. Personal email id : [e-mail]

Comment 1

[Leo]

Attachment: Cannot accept second call

Comment 2

[Arthur Chen [:arthurcc][inactive after 6/30]]

The fix is to add a check on 'telephony.active' in the 'holdAndAnswer' function, which is simple. But we still need to define the behavior in related conditions.

- If the first call is held, how does the UI look like when there is a second call? Currently it still displays a "hold" icon representing answering the second call.
- If the first call is held and users answer the second one then hang it up, should we resume the first call or not?

Comment 3

[Beatriz Rodríguez [:brg]]

There is another bug asking for removing call hold as it is now:
https://bugzilla.mozilla.org/show_bug.cgi?id=894232
Please check the feedback there and we can postpone this issue to v1.2

Comment 4

[Stephany Wilkes]

Conference calls and call waiting are 1.2 features and are in progress with the Communications agile team. Given that, I don't believe this should be a 1.1 blocker.

I am also flagging Francis just in case there is more that should be noted here.

Comment 5

[Beatriz Rodríguez [:brg]]

Call waiting is included since v1.0.1 version

Comment 6

[Francis Djabri [:djabber]]

Attachment: HTML5_Dialer_Contacts_20120810_R2S1_V6.0.pdf

> - If the first call is held, how does the UI look like when there is a
> second call? Currently it still displays a "hold" icon representing
> answering the second call.

Please refer to the attached UI spec, page 28, for current behavior. Bug #882056 also suggests an updated UI - the hold icon should be replaced by the text "Hold" to disambiguate. 

> - If the first call is held and users answer the second one then hang it up,
> should we resume the first call or not?

yes, we should resume the call. Please refer to the attached UI spec, page 29.

Comment 7

[Arthur Chen [:arthurcc][inactive after 6/30]]

Francis, I realize that the icon will be replaced with the text after bug 882056 lands. What I was asking was, if the first call is already held, do we still need to display the "hold" button?

Comment 8

[Beatriz Rodríguez [:brg]]

adding dependency of a bug that is trying to remove the call hold action in 1.1.

Comment 9

[Francis Djabri [:djabber]]

(In reply to Arthur Chen [:arthurcc] from comment #7)
> Francis, I realize that the icon will be replaced with the text after bug
> 882056 lands. What I was asking was, if the first call is already held, do
> we still need to display the "hold" button?

Arthur, we still need to provide a way for the user to answer the incoming call without ending the call on hold. I think the best way to handle this is to use the standard incoming call view that allows the user to either answer or reject a call. In both cases, the call on hold will remain on hold.

Comment 10

[Arthur Chen [:arthurcc][inactive after 6/30]]

Introducing the second standard incoming call seems a huge effort and may impact the code quality. I would like opinions from Etienne. A simpler solution would be altering the 'hold' text with 'answer' in this case. Would that be acceptable?

Comment 11

[Francis Djabri [:djabber]]

"Answer" here is misleading as the button refers to the call on hold, not the incoming call. I would suggest that we just keep the text as "Hold".

Comment 12

[Arthur Chen [:arthurcc][inactive after 6/30]]

Attachment: link to https://github.com/mozilla-b2g/gaia/pull/11336

Per the previous comment, we keep the original behavior and only do a null check on telephony.activeCall in this case. Etienne, could you help review the patch? Thanks!

Comment 13

[Etienne Segonzac (:etienne)]

Comment on attachment 785631 [details]
link to https://github.com/mozilla-b2g/gaia/pull/11336

r=me
This is a clean patch fixing the bug as described.

Concerning the call waiting UX, I'm all for making it a bit clearer but we can do this on a different bug :)

Comment 14

[promise09th]

In leo device, because of operator spec(User can hold call if not use BT devcie), we can't apply Bug 894232 patch.
And, When I apply this patch, I can accept and ignore second call, but I can't end call(Red button).

Please check this.

Comment 15

[Etienne Segonzac (:etienne)]

(In reply to promise09th from comment #14)
> In leo device, because of operator spec(User can hold call if not use BT
> devcie), we can't apply Bug 894232 patch.

Bug 894232 is specially for Leo device but you can't apply it for leo device??

> And, When I apply this patch, I can accept and ignore second call, but I
> can't end call(Red button).

Which call the first or the second?

Comment 16

[Stephany Wilkes]

Flagging Francis on this again, to check in and clarify as necessary. While UX could be handled in another bug, the issue began when the feature wasn't implemented to spec, which there is a history of here.

Comment 17

[promise09th]

First call is already connecting call, second call is receiving call when already connecting call.
I'm sorry to confuse you

Comment 18

[Arthur Chen [:arthurcc][inactive after 6/30]]

I cannot reproduce the bug as comment 14. Does it happen after applying the patch?

Comment 19

[Leo]

Attachment: After applying patch

Comment 20

[promise09th]

Please see attachment 786797 [details]

Current apply status : 
Apply to Merge pull request #11045 from cctuan/893269-2
(But not apply "Bug 862385 - Cache contact names for the call log" patch)

Comment 21

[Arthur Chen [:arthurcc][inactive after 6/30]]

Comment on attachment 785631 [details]
link to https://github.com/mozilla-b2g/gaia/pull/11336

The bug described in comment 14 is not resulted from the patch, but the root cause is the same. To get the first call, we should retrieve it from handledCalls array instead of using telephony.active as it is null in certain conditions. 

Etienne, I've rewrote the patch, could you help check it again? Thanks!

Comment 22

[Etienne Segonzac (:etienne)]

Comment on attachment 785631 [details]
link to https://github.com/mozilla-b2g/gaia/pull/11336

2 smalls comments on github.
This change makes sense, we're almost there.

Comment 23

[Arthur Chen [:arthurcc][inactive after 6/30]]

Comment on attachment 785631 [details]
link to https://github.com/mozilla-b2g/gaia/pull/11336

Patch revised based on the comments. Please help review it again, thanks!

Comment 24

[Etienne Segonzac (:etienne)]

Comment on attachment 785631 [details]
link to https://github.com/mozilla-b2g/gaia/pull/11336

Awesome thanks!

Comment 25

[Arthur Chen [:arthurcc][inactive after 6/30]]

Thanks for reviewing!

master: https://github.com/mozilla-b2g/gaia/commit/693a0100857827ebf2ef35efd8710852b8564574

Comment 26

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted 693a0100857827ebf2ef35efd8710852b8564574 to:
v1-train: 14555d002c3f7a2504bdd7433c77eef271a16a12

Comment 27

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

v1.1.0hd: 14555d002c3f7a2504bdd7433c77eef271a16a12