In 3.0, the packet loss metric used to trigger connection status alerts was
changed to the one generated by the `startMonitoringNetwork` method used by the
connection status modal. Since packet loss thresholds were not adjusted (0.5,
0.1, 0.2), a single lost packet causes the status alert to be permanently
stuck on "critical". This is explained by how different those metrics
are:
- **Before (2.7):** A 5-probe wide calculation of inbound packet loss
fraction based on `packetsLost` and `packetsReceived` metrics.
- **Now (3.0):** An absolute counter of inbound lost packets.
This commit restores the previous packet loss metric used to trigger
connection status alerts, reverting to the original collection method via
`/utils/stats.js`. This resolves the issue, but further work is needed in
subsequent PRs:
- Unify the collection done in `/utils/stats.js` with the
`startMonitoringNetwork` method.
- Incorporate the remote-inbound `fractionsLost` metric to account for packet
loss on both legs of the network (in/out).
- Update the packet loss metric displayed in the connection status modal to
show a more meaningful value (e.g., packet loss percentage over a specific
probe interval). An absolute counter of lost packets isn't useful for end
users.
- Update the alert log to use the fraction or percentage above
UI team suggested a few adjustments to the audio settings modal:
- Larger (24px/1.5rem) margin between content and headers
- Rephrasing of modal title, subtitle and volume indicator label
- Change the "audio feedback" button to an outline or link styled
button (there are currently two primary buttons and we want users to
focus on the "Join audio" one)
Implement the suggested changes. The approach for the audio feedback
button is link-styled.
* The prop presentationIsOpen is marked as required in Presentation(null)
* The prop isPresentationManagementDisabled is marked as required in actions-dropdown(null)
* The prop autoJoin is marked as required in wake-lock(null)
* Al children must have key identifiers (userListParticipants)
* The prop presentationUploadExternalDescription is marked as required in presentation-uploadres
Safari may enter a microphone permission check loop due to buggy behavior
in the Permissions API. When permission isn't permanently denied, gUM
requests fail with a NotAllowedError for a few seconds. During this time,
the permission state remains 'prompt' instead of transitioning to 'denied'
and back to 'prompt' after the timeout.
This leads to an issue where, on retrying while in 'prompt' + blocked,
the client loops through gUM checks via: 1) checking permission in the API,
2) receiving 'prompt', so trying gUM, 3) gUM fails, 4) returning to the
modal and checking permission again because the API still says 'prompt'.
Additionally, the `isUsingAudio` flag incorrectly counts the local echo
test/audio settings modal as "using audio," which toggles the flag on/off,
triggering the useEffect that causes the loop more frequently.
To fix this, remove the unnecessary AudioModal permission check that
causes the loop. Also, exclude "isEchoTest" from the `isUsingAudio` flag.
Firefox incorretly displays placeholder audio device labels in the audio
settings/echo test modal when audio is disconnected. This issue arises
due to two quirks:
- Firefox does not support the 'microphone' query from the Permissions
API, causing a fallback gUM permission check.
- Firefox omits device labels from `enumerateDevices` if no streams
are active, even if gUM permission is granted. This behavior differs
from other browsers and causes our `enumerateDevices` handling to
assume that granted permission implies labels are present. This
failed since we clear streams before resolving the fallback gUM.
We now run an additional `enumerateDevices` call in `AudioSettings` when
a selected input device is defined. This ensures `enumerateDevices` is
re-run when a new stream is active, adding the correct device labels in
Firefox and improving device listings in all browsers. We've also
enhanced error handling in the enumeration process and fixed a false
positive in `hasMicrophonePermission`.
There's a regression in 3.0's I/O device selector where default output
devices are not marked as selected in the input-stream-live-selector
component unless the user explicitly selects them. This issue can also affect
input devices, although less commonly than output due to the system's ability
to infer the selected input device ID after the user joins audio.
When a device is the first in the list and no currentDeviceId is set in
the client, treat the first device returned by enumerateDevices as the
system default and hence selected, in accordance with the "Media Capture
and Streams API", Section 9.2, enumerateDevices algorithm.
* test: update and improve Ask for feedback on logout test - add more steps, check for different buttons, check POST request after sending feedback
* test: add missing data-test prop for sendFeendbackButton
* test: fix sendFeedbackButton data-test
When `listenOnlyMode` is `false` and the audio dialog's "Cancel" action is
clicked, the modal incorrectly re-renders instead of closing. Additionally,
the "Cancel" action is mislabeled as "Back."
This fix ensures the audio dialog closes properly when there are no options
to select (i.e., `listenOnlyMode=false`). The `skipAudioOptions` method is
revised to consider `listenOnlyMode` and ignore the "content" state.
Ignoring the "content" state allows options to be skipped even if a subscreen
is rendered (e.g., returning from the AudioSettings modal). The check for
`content == null` combined with `skipAudioOptions` is only necessary when
rendering the main modal. The `content == null` check has been moved to
the relevant section.
Prevents changes in the presentation state while sharing media from
updating the presentation last state value. Additionally adds a missing
prop value of generic content state.
Removes the duplicate presentation pile dispatch for external video, as
an identical dispatch runs when the external video component is mounted.
This duplication did not cause any noticeable issues for the user but
resulted in the external video being added to the pile twice.
The plugin loader startup logs aren't following the logger convention,
which makes them hard to work with when post-processing logs.
The appended error message is also not useful since we're logging a
Event variant raw (which either outputs {} or nonsense like { isTrusted:
etc }).
Make the plugin "loaded" and "error" logs adhere to logger conventions.
In the future, the error log could use some tuning - there's no useful
info about root cause here.
