1083402 - "X has left the conference call" when a party drops off a conference call is missing

Status: RESOLVED DUPLICATE of bug 1089534

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

Description

[Tamara Hills [:thills]]

While implementing Bug 1068093 - Remove legacy transitions from the callscreen, was trying to figure out if the code to display "X has left the conference call" can be removed.  

This message no longer shows up in 2.0 and above, so wanted to check with you if it's ok to remove this.

The thought was that this is replaced by the separate calls and the dropped party momentarily in red.

Comment 1

[Tamara Hills [:thills]]

Hi Carrie/Etienne,

Wanted to find out if this functionality should be removed as per your understanding.  

Etienne, We saw this was added as a feature in 1.4 and it is not there in 2.0.  Just curious if it was intentionally removed or if it was broken and we're just now finding it.  

Thanks,

-tamara

Comment 2

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

Hi Tamara, 

Is this "X has left the conference call" a notification? If it is, then I don't remember that we have removed it, and I don't think we should. Thanks!

Comment 3

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

Attachment: Dialer UX Spec 0.7(1).pdf

see p.17.

Comment 4

[Etienne Segonzac (:etienne)]

Looks like a regression from the visual refresh... :/
The message should appear on the callscreen even (only?) when the group details list is not displayed so we might still need it.

Comment 5

[Doug Sherk (:drs) (inactive)]

[Blocking Requested - why for this release]: No notification appears when someone on a conference call drops and the conference call is still ongoing. This is actually broken on 2.0 as well, but that ship has sailed.

Carrie, Carol, do you know if there is an updated UX and/or UI spec for this? I looked around and couldn't find one.

Comment 6

[Johan Lorenzo [:jlorenzo]]

Per comment 0 and comment 1.

Comment 7

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

triage: we shipped 2.0 with this even though it was a regression. it's not critical so we decided not to block at this moment.
 
Carrie,
If UX thinks this is essential, please go ahead and nominate to 2.2.

Comment 8

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

There was another bug working on displaying the time duration when participants drop the call, other than that we didn't implement new features (as far as I know). So no spec updated at the moment, but the visual does look quite different now. Thanks.

Comment 9

[Germán Toro del Valle (:gtorodelvalle)]

Yeah, Carrie is referring to bug 977056, I think ;) As Carrie mentions, I am not aware of any change regarding this status message shown when a participant leaves a conference call and consequently it should be shown :)

Apart from that, and as suspected, in v2.2 the issue is related to the event notification flow and data we are currently observing and discussing in bug 977056. More concretely, right now the groupchange event is being notified to the hung up call (the one which left the conference call) with the event.call.state property as 'connected'. According to the already existent code which worked in the past :) (see https://github.com/mozilla-b2g/gaia/blob/master/apps/callscreen/js/handled_call.js#L86) and also to what we have observed in bug 977056, this seems to have changed 'lately'. BTW, this is also causing the misbehaviour mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=977056#c26 which dates from 2014/08/15.

Summing it up, with the current event and data flow observed in v2.2, there's no (safe) way to know which call is the hung up one and which one is the still ongoing one and consequently the message is not shown (in fact both calls are considered as unmerged which is obviously not possible) :(

As I have suggested in bug 977056, I think revisiting and specifying (as we already did in https://bugzilla.mozilla.org/show_bug.cgi?id=977056#c54 for a very concise case) the event notification and data flow for most if not all the possible calling scenarios is becoming more and more necessary since it is the cause of many of the bugs we are currently observing in the call screen.

I'll check the behaviour in v2.0 and v2.1 according to comment 6 and I'll share my findings.

Comment 10

[Carol Huang [:Carol]]

If we have the notification, "X has left the conference call" will pop-up as the In-App notification. So i believe there's no graphic works. thanks!

Comment 11

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

ni? to Johan for 1.4 behavior checking.

Comment 12

[Johan Lorenzo [:jlorenzo]]

Attachment: End of conference - 2.0 - video

Here's what's happening in 2.0. No message is present like in 1.4. Is this interaction in line with what UX expects?

Comment 13

[Johan Lorenzo [:jlorenzo]]

I forgot to mention: I checked 1.4 on buri. When a user leave the conference, the message is correctly displayed.

Gaia-Rev        b06fee13c1d80bd2a463be1f2fb1d59169af9298
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/540ef440c9a9
Build-ID        20141013000203
Version         30.0
Device-Name     msm7627a
FW-Release      4.0.4
FW-Incremental  eng.tclxa.20131223.163538
FW-Date         Mon Dec 23 16:36:04 CST 2013

Comment 14

[Germán Toro del Valle (:gtorodelvalle)]

Hi guys! I just confirmed that the issue reproduces in v2.1 due to the same reason as in v2.2. This is, the groupchange is notified to the hung up call with event.call.state to 'connected', this added to the rest of events and data provided from the RIL results in no (safe) way to know which call is the ongoing one and which one is the ended one from the conference call.

On the other hand and as an 'evidence' of this, you'll also notice what I mention in the first paragraph of https://bugzilla.mozilla.org/show_bug.cgi?id=977056#c26 Just the same as what can be observed in v2.2.

Going down to v2.0... ;)

Comment 15

[Germán Toro del Valle (:gtorodelvalle)]

Hi again! I just confirmed that the issue reproduces in v2.0 due to the same reason as in v2.2 and v2.1. This is, the groupchange is notified to the hung up call with event.call.state to 'connected', this added to the rest of events and data provided from the RIL results in no (safe) way to know which call is the ongoing one and which one is the ended one from the conference call.

On the other hand and as an 'evidence' of this, you'll also notice what I mention in the first paragraph of https://bugzilla.mozilla.org/show_bug.cgi?id=977056#c26 Just the same as what can be observed in v2.2 and in v2.1.

Comment 16

[Germán Toro del Valle (:gtorodelvalle)]

So my conclusion is that some update in the Telephony part of Gecko has been applied to v2.2 and has been uplifted to v2.1 and v2.0.

We should clarify which event notification and data flow is the right one for this calling scenario (a participant leaving a conference call) and adapt the Call Screen app accordingly.

Need-infoing Hsin-Yi and Doug since I guess it is something both teams should coordinate and agree on. Thanks!

Comment 17

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Germán Toro del Valle from comment #16)
> So my conclusion is that some update in the Telephony part of Gecko has been
> applied to v2.2 and has been uplifted to v2.1 and v2.0.
> 
> We should clarify which event notification and data flow is the right one
> for this calling scenario (a participant leaving a conference call) and
> adapt the Call Screen app accordingly.
> 
> Need-infoing Hsin-Yi and Doug since I guess it is something both teams
> should coordinate and agree on. Thanks!

Hi Germán,

I've replied on bug 977056. How about we keep discussion there so that we won't have divergent threads. :P

(In reply to Germán Toro del Valle from comment #15)

> Hi again! I just confirmed that the issue reproduces in v2.0 due to the same
> reason as in v2.2 and v2.1. This is, the groupchange is notified to the hung
> up call with event.call.state to 'connected', 

This 'connected' is not the design. Bug 1059649 should fix this that no redundant 'connected' event fired on the hang-up call.

> this added to the rest of
> events and data provided from the RIL results in no (safe) way to know which
> call is the ongoing one and which one is the ended one from the conference
> call.
> 
> On the other hand and as an 'evidence' of this, you'll also notice what I
> mention in the first paragraph of
> https://bugzilla.mozilla.org/show_bug.cgi?id=977056#c26 Just the same as
> what can be observed in v2.2 and in v2.1.

Comment 18

[Germán Toro del Valle (:gtorodelvalle)]

Yeah, yeah, agreed ;) Just tried to inform the people interested in this bug since it was going through triage so they could have all the needed information to make the proper decisions ;)

In fact, just with the same intention, let me inform you that as Hsin-Yi mentions in the previous comment, this bug will probably be fixed by the patch for bug 1059649. I'll track it and inform you accordingly.

We can continue our discussions about the proper event notification flow and data in bug 977056 :p

Comment 19

[Doug Sherk (:drs) (inactive)]

Let's keep the discussion in bug 977056.

Comment 20

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

Hi, as comment2, the expected behavior is displaying the message to inform users in this case. Thanks!

Comment 21

[Germán Toro del Valle (:gtorodelvalle)]

I just confirmed that after applying the patch proposed by Hsin-Yi to bug 1089534, the issue reported in this bug is solved ;)

This was expected since that patch takes us closer to implementing the "participant leaving a conference spec" as defined in attachment 8510217 [details] (see bug 977056 for all the details).

I'll track the evolution of bug 1089534 and evolve this one accordingly ;)

Comment 22

[Germán Toro del Valle (:gtorodelvalle)]

Just to keep track of all the known dependencies in case the updates needed to solve this bug are finally uplifted to previous versions ;)