Multiple undefined accesses in actions-bar's service, mainly related to
breakouts and ageneral Meetings info, cause crashes in production
environments - most likely in reconnection scenarios.
Guarantee that nested data is safely accessed.
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.
A client crash may happen if either the Meeting collection or the
document's metadataProp attribute are undefined whenever the
getFromMeetingSettings util is called to fetch metadata.
It's debatable whether anything is working in the client if the
documents being accessed here are unavailable, but it'll still be logged
and might bork an ongoing reconnect.
Use optional chaining + nullish coalescing to avoid causing TypeErrors
in those situations while also returning default metadata values
properly.
When a sendrecv peer acts as the answerer, gUM is only called _after_
the remote offer is received. This is fine, but the error handling runs
different in that scenario in a way that eventual gUM errors are treated
as negotiation errors, leading to inconsistencies when surfacing the
error to end users.
If a peer is acting as answerer and is a transceiver, acquire the local
streams _before_ actual negotiation so that gUM errors are surfaced
correctly (and we spare uneeded negotiation steps).
The client may crash whenever a emoji rain animation is triggered, but
the interactions button element cannot be located. This happens because
the button coordinates are fetched without checking whether the element
exists.
Get the coordinate fetching method to return null if the
interactionsButton element cannot be located, and ignore the emoji rain
action if that is the case. Whenever no valid coordinates are found, log
an warning so we can track this and figure out what's happening with the
button.
Fix a few typos in the getInteractionsButtonCoordinates method.
Audio exit toasts are fired in some redundant situations, e.g.: when the
error help screen is toast.
Change the logic a bit so that it's only fired when the audio help modal
won't be shown, i.e.: when audio had succesfully connected.
There are some scenarios (e.g. WKWebView) where Bowser can't detect the
Safari version number correctly, which leads to a client crash due to an
invalid string.split call in UnsupportedComponent.
In such cases, use the WebKit version to determine it. If that's not the
case and the version number is still unavailable, log an warning and
return Infinity so that we do not deny access to the user (even if
we're uncertain about whether it's a supported browser);
