Listen only has a built-in retry routine on join failures that's
convoluted half-broken. It stems from the Kurento era where it could
fail randomly due to a myriad of reasons.
Production logs indicate that the retry is seldom used nowadays in
mediasoup-based environments. The presence of the retry also breaks
the error troubleshooting modal when actual failures happening, leaving
users in the dark about what's happening.
Remove the listen only retry code from AudioManager and bubble up any
join failure to the callers.
WebRTC-based stats generation in the connection status modal is broken
on Firefox >= 125. A broken type check coupled with a new partially
implemented RTCIceTransport dictionary causes and undefined function
call when fetching the selected candidate pair. Since that error is
unhandled, collection breaks.
Correctly check for the getSelectedCandidatePair method availability in
RTCIceTransport so that it skips to pair inference from getStats if
necessary.
Forces the toolbar width to be the maximum available width, which is
the width of the media area, on mobile devices. Also allow the toolbar to
overflow with an horizontal scroll when the available width is not enough
to display all of its contents.
In scenarios where the join audio flow skips echo test, NotAllowedError
(and any other errors) are all being mashed together under a generic
MEDIA_ERROR object.
Properly handle specific errors in audio-manager so they're correctly
render in the audio modal help screen.
- Adds a new Help view for unknown error codes
- Correctly detect NotAllowedError (permissions) - they are currently
being treated like unknown errors in the Help modal
- Rephrase NotAllowedError help text; make it more succint and direct
- Rephrase the unknown error help text; make it more succint and direct
- Add error code and message to that view
- Add public.media.audioTroubleshootingLinks to allow referencing KB
links on the Help modal
- See inline docs
There's a race condition that may cause a client crash whenever a
connectionstatechange callback is cleaned up in a peer without a
valid peer connection present in our custom RTCPeerConnection wrapper.
Check for peerConnection availability in the WebRtcPeer wrapper before
trying to clean up its connectionstatechange callback.
There's a race condition that may cause a client crash whenever a
video-provider's unmount procedure is run, but its signalling websocket
is undefined. The WS's callback handlers are re-assigned without
checking for the socket's availability, causing an unhandled TypeError.
The WS may be undefined in a couple of scenarios, e.g.: unmouting before
the socket was successfully set up, unmounting while a reconnect is in
place etc.
Check whether the socket exists before accessing it in video-provider's
componentWillUnmount routine.
