Client not responding to actions while reconnecting

[antobinary]

Describe the bug I was in a call and visually all seemed fine. I was toggling myself muted/unmuted every few seconds. At some point I could no longer unmute myself even though visually there was no problem -- webcams were running, I could hear audio. My connection status was green-ish and at some point later purple. I kep hitting the unmute button and it would add a line in the browser console (expected) but would not take effect (unplanned). I am not sure how to reproduce. When I have more info I will include it in this issue.

This issue is meant as a placeholder as this has been happening to me a few times now and it's been diagnozed as "network congestion for X seconds" before. Others have also hit / debugged similar cases.

My main problem was that my client did not inform me of what was going on, and instead just acted unresposive.

To Reproduce Steps to reproduce the behavior: ...

Screenshots

BBB version: BigBlueButton 2.6.0-alpha.2 although I have seen the same on 2.5.3

[antobinary]

at 14:39:07 this is what my connection status looked like

and this is not a super helpful post-mortem

[prlanzarin]

I am not sure how to reproduce. When I have more info I will include it in this issue.

Trigger a network block on Meteor's signaling channel that does not immediately cause a channel shutdown. That can be achieved by pulling the network cable/switching off Wi-Fi, switching in and out of VPNs, bringing the network interface down for a short period of time or things of the sort. Eventually the signaling channel will just reconnect, but it takes an unhealthy amount of time to do so. UI stays inconsistent in the meanwhile.

The expected behavior can be seen by running a Meteor.disconnect() from the console - which immediately flags Meteor as disconnected and blocks the UI for some signaling-dependant tasks (mute, chat, etc). So yeah, detecting outages earlier would help.

[prlanzarin]

Also worth noting that this is not a regression from anything - it's been the behavior since 2.2/whatever the first HTML5 client release was.

There's also the argument that some specific things should not be signaling dependant the way they are (eg mute/unmute) - while that's correct, it's another issue entirely that should be covered separately. I believe this is already where this issue's aimed at, but just to emphasize: I suggest constricting its scope to UI consistency.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.