* test: all param tests on ci
* test: remove check for notification on parameter test
* test: remove 'Force restore presentation on new poll result' test - keep only one using the parameter -, fix selector and add all necessary assertions for the cases when the presentation should be restored
* test: enable param test in CI
* test: update tests tagging
* 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
mediasoup workers are currently for general use,
regardless of stream type. This makes it difficult to give
different scheduling priorities for audio workers or prevent
noise from video streams, when our goal is to give higher
priority to audio in all ends of the system.
Set `mediasoup.dedicatedMediaTypeWorkers.audio` to `auto`. This will spin up
`ceil((min(nproc, 32) * 0.8) + (max(0, nproc - 32))` mediasoup workers
dedicated to handling audio streams.
See https://github.com/bigbluebutton/bigbluebutton/issues/20966.
The order of the configured mediasoup listenIps influence the server's candidate priorities.
There's not a big impact to this, but if we want to be friendly to RFC 8421 (and to Happy Eyeballs), we should suggest sorting IPv6 first.
Change docs so that the IPv6 config in mediasoup comes first.
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.
When listen only mode is deactivated and an user joins audio, an incorrect
remount of AudioSettings can trigger a spurious mute toggle. This happens
because AudioManager clears the `isConnecting` flag before setting the
`isConnected` flag. This creates a brief period where audio is flagged as
"disconnected," leading to a remount and unmount cycle that causes unwanted
mute/unmute actions due to AudioSettings' logic of muting/unmuting
active devices.
Ensure the `isConnected` flag is set before clearing the
`isConnecting` flag, preventing audio from being incorrectly flagged as
disconnected.
