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
The ErrorBoundary component has a generic log message that is not
overridable and will aggregate errors from different components. The
ideal scenario is that log tags are configurable so that errors can be
filtered for in log post-processing.
Add the logMetadata: { logCode, logMessage } prop to the ErrorBoundary
component so that log tags are configurable. Default tags are
maintained.
Add specific log metadatas for the client startup error boundary
(logCode: 'app_startup_crash') and the user connection error boundary
(logCode: 'app_crash').
Mobile users have no way to change I/O devices after joining audio.
The removal of the audio options chevron in mobile browsers was supposed
to be replaced by something else - in this case, by the dedicated
leave/join audio button. That didn't happen, leave/join audio button
retained the old behavior.
Review device selection in mobile endpoints via two UI/UX changes:
- Fix an styling issue where the mute and listen only buttons were
crammed together
- Restore the device selection chevron/icon in mobile endpoints
- Override the leave/join button action in mobile endpoints so that it
opens the device selection contextual menu, which also includes the
"Leave audio" option. This retains the old behavior (leaving audio)
while also providing an way for users to change devices mid-call in
mobile browsers.
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.
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.
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.
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.
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).
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.
