1083760 - [Loop] Doesn't always clear the "Connecting" display (mainly audio-only calls?)

Status: RESOLVED FIXED

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

Description

[Mark Banner (:standard8)]

Using revision c52321f9bb4d9ad2ade8b0d43ad719f8bae01972 on Gaia 2.2, and Firefox Nightly.

STR:

1) On Firefox desktop, initiate an audio-only call to a flame device
2) Accept the call with audio-only

Actual Results

- The call is connected, and audio can be heard at both ends
- The Flame device continues displaying "Connecting"

Expected Results

- The Flame device shows "Connected" and/or the avatar of the contact (or a default image as desktop currently does)

Comment 1

[Mark Banner (:standard8)]

I've just gone back to video calls, and I've noticed that "Connecting" is remaining on those as well.

Not sure if I just didn't notice it earlier, but I've restarted both ends, and "Connecting" still doesn't go away during video calls even when its fully connected.

Comment 2

[José Antonio Olivera Ortega [:jaoo]]

Hey Song, we need your help here. We wait for the 'loaded' event (see at [1] please) on the subscriber object to change the UI, drop the string 'Connecting' and show the counter. Sometimes this function is not called and the A/V is available on both ends. I don't know how we could poke around. Any ideas? Thanks!


[1] https://github.com/mozilla-b2g/firefoxos-loop-client/blob/master/app/call_screen/js/call_manager.js#L402

Comment 3

[José Antonio Olivera Ortega [:jaoo]]

Just reproduced this issue and something wrong showed up in the logs. Hope it helps Song.

E/GeckoConsole( 1146): [JavaScript Error: "TypeError: stream.connection is undefined" {file: "app://loop.services.mozilla.com/libs/tokbox/v2.2.9.1/js/TB.js" line: 20485}]

Comment 4

[mozilla-support]

@Jose, the error stream.connection is a race condition caused when streamCreated event gets fired before connectionCreated event. This bug is fixed in OpenTok 2.2.9.3 patch. This should not cause this particular issue. I can reliable reproduce this issue on my device, and here is what I discovered:

* I added some console log statements in [1] to see if subscriber loaded event is getting called and if CallScreenUI.setCallStatus("connected") gets fired. They are. No problems here.

* I added some console log statements in [2] to see what states are being set. The resulting logs shows that somewhere in the code, setCallStatus("connecting") is getting called again, AFTER setCallStatus("connecting"). Here are the logs:
:336 in CallScreenUI.setCallStatus: *********
:337 in CallScreenUI.setCallStatus: *********
:338 in CallScreenUI.setCallStatus: setting call status: connecting
:339 in CallScreenUI.setCallStatus: *********
:340 in CallScreenUI.setCallStatus: *********
:420 in CallManager.join/<.streamCreated: SETTING EVENT HANDLER
:423 in CallManager.join/<.streamCreated/<.loaded: OpenTok SUBSCRIBER LOADED
:336 in CallScreenUI.setCallStatus: *********
:337 in CallScreenUI.setCallStatus: *********
:338 in CallScreenUI.setCallStatus: setting call status: connected
:339 in CallScreenUI.setCallStatus: *********
:340 in CallScreenUI.setCallStatus: *********
:427 in CallManager.join/<.streamCreated/<.loaded: setting call status to connected
:336 in CallScreenUI.setCallStatus: *********
:337 in CallScreenUI.setCallStatus: *********
:338 in CallScreenUI.setCallStatus: setting call status: connecting
:339 in CallScreenUI.setCallStatus: *********
:340 in CallScreenUI.setCallStatus: *********
:336 in CallScreenUI.setCallStatus: *********
:337 in CallScreenUI.setCallStatus: *********
:338 in CallScreenUI.setCallStatus: setting call status: ending
:339 in CallScreenUI.setCallStatus: *********
:340 in CallScreenUI.setCallStatus: *********
:336 in CallScreenUI.setCallStatus: *********
:337 in CallScreenUI.setCallStatus: *********
:338 in CallScreenUI.setCallStatus: setting call status: ended
:339 in CallScreenUI.setCallStatus: *********
:340 in CallScreenUI.setCallStatus: *********

* I think a possible fix would be to check to make sure that call is not currently is progress before setting callstatus to connecting. In a statemachine, a transition from connected to connecting should not be possible anyways. It seems that connecting status is getting set in [3].

Hope this helps!

[1] https://github.com/mozilla-b2g/firefoxos-loop-client/blob/master/app/call_screen/js/call_manager.js#L425
[2] https://github.com/mozilla-b2g/firefoxos-loop-client/blob/master/app/call_screen/js/call_screen_ui.js#L336
[3] https://github.com/mozilla-b2g/firefoxos-loop-client/blob/master/app/call_screen/js/call_manager.js#L143

Comment 5

[José Antonio Olivera Ortega [:jaoo]]

Thanks for these findings here Song. It seems the A/V media element start playing even before the call set up protocol finishes. The fix might be on the client (app) side then.

Comment 6

[José Antonio Olivera Ortega [:jaoo]]

Attachment: Pointer to Github PR https://github.com/mozilla-b2g/firefoxos-loop-client/pull/336

Let's pair up for this review Borja so we could land this soon. Thanks!

Comment 7

[Borja Salguero [:borjasalguero]]

Comment on attachment 8529264 [details] [review]
Pointer to Github PR https://github.com/mozilla-b2g/firefoxos-loop-client/pull/336

R+. Please rebase properly when the other bug will be merged! Thanks!

Comment 8

[José Antonio Olivera Ortega [:jaoo]]

Landed on master branch at:

https://github.com/mozilla-b2g/firefoxos-loop-client/commit/8d4512eaf8c6ddc78f6a0484846e80678ca90296

Comment 9

[José Antonio Olivera Ortega [:jaoo]]

Landed on 1.1 branch at:

https://github.com/mozilla-b2g/firefoxos-loop-client/commit/cfe2c99aa6d169f5910e88b49faa3f9a0f587fc2