* feat(screenshare): add support for troubleshooting links
Adds setting option to specify troubleshooting links to each error code
of screenshare. When a troubleshooting link for the given error exists,
the toast notification about the error is displayed with a 'Learn more'
button that when clicked leads the user to the external link. When there
is no link set for the specific error code, the button is not displayed.
* fix(screenshare): change toast type for error code 1136
Changed toast type from 'error' to 'warning' for error code 1136 when
sharing screen. This adjustment was made because error code 1136 is also
returned when the user cancels screen sharing during the tab selection
process. Displaying an error toast in this situation could cause
unnecessary alarm for users, as they were simply canceling an operation.
* fix(notification): help link button element
Uses the button element instead of a div to display the 'Learn more'
help link button.
---------
Co-authored-by: Carlos Henrique <carloshsc1998@gmail.com>
We are missing a way to select transcription languages in some
scenarios, e.g.: listenOnlyMode=false. The audio settings UI is also not
handling item disposition very well on smaller devices.
This commit does the following to improve those blind spots:
- Add the transcription language selector to it whenever applicable
- Add proper styling to the transcription selector
- Handle small screens by changing the disposition of elements to
portrait mode
- Improve how elements are disposed to a more familiar view: Mic ->
Activity Indicator; Speaker -> Speaker test. This is more in line
with how other platforms do audio configuration/pre flight screens.
Support for bbb-html5's server logger (Winston) was removed in
50d445f026, but configuration for it
remained.
Remove the Winston-based server logger configuration from bbb-html5's
settings.yml. There's no direct alternative since this package hasn't got a
server side component to it - replaced by bbb-graphql-middleware,
bbb-graphql-server and bbb-graphql-actions.
Support for clientLog's "server" target (Meteor) was removed in
50d445f026, but configuration and docs
entries for it remained.
There's no alternative for it, so I'm removing the leftover
configuration and doc entries.
Jitter evaluation, as an alert trigger, was changed in 3.0 to get the internal
average jitter used in the conn-status component data (which is total jitter
delay divided by jitterbuffer emit events). This was done accidentally and that
metric is _very_ different from the one used in 2.7 (point-in-time jitter from
remote-inbound-rtp/inbound-rtp, highest on the interval, gathered on
/utils/stats.js). The alert thresholds were preserved, which makes it overly
sensitive in regards to jitter (and thus causes it to be critical whenever the
user is in audio).
Remove jitter as a connection status alert trigger, which fixes the
false positive. The implementation on <= 2.7 is also not ideal - if
anything, it generates false negatives. That's why I'm removing jitter for
the time being since it's ill-suited (at least in the way it's used)
for what we want to achieve.
* feat(graphql-server): add new view `v_chat_private_read_feedback`
Adds a view called `v_chat_private_read_feedback` to retrieve the last seen time
of the recipient of a private chat.
* refactor(chat): removes unused prop `lastSeenAt`
* feat(private-chat): message read confirmation feedback
Adds message read confirmation feedback feature to private chats.
This feature uses the private chat recipient's `lastSeenAt' attribute to
check which messages were read. Messages read are show in the chat with
a check icon next to it.
Feature behind a flag in settings.yml, which is disabled by default:
- `public.chat.privateMessageReadFeedback.enabled`
* fix(chat): poll chart message
Fixes poll chart message which was not using the full chat width due to
previous changes in chat messages `flex-direction`.
* fix: adds missing initial value for `privateMessageReadFeedback`
* fix: linter errors
* fix(chat): add `recipientHasSeen` property to existing view
This commit changes the way the messages read by the recipient are
tracked. The previous strategy required the client to calculate the read
messages and as a consequence all messages of the given chat
were re-rendered every time the recipient `lastSeenAt` time
changed. The current strategy consists of calculating the read messages
on the server(based on recipient `lastSeenAt`) and just expose to the
client a boolean(`recipientHasSeen`) for each message that indicates whether
it has already been read or not.
* fix: typo in message description
* fix: typo in settings flag
* fix: vertically align icon
* feat(webcams): skip video preview if valid input devices stored
Additionally:
- refactor: re-use the existing VirtualBackground_* storage info instead
of creating a new one
- fix: store background choices per deviceId instead of globally
- fix: guarantee background restore attempts are *critical* when
video-preview is supposed to be skipped. We want the preview to be
shown if the previous background could not be restored to preserver
the user's privacy choice
- fix: cameras could not be shared if no previous device info was in
the user's session
- fix: uploaded background images were not correctly restored
- fix: do not spin up virtual bg workers for brightness if it has not
been altered by the user
- refactor: remove old video-provider background restore routine,
centralize it in video-preview
* fix(skip-video-preview): correct storage check and add playwright test and docs
---------
Co-authored-by: prlanzarin <4529051+prlanzarin@users.noreply.github.com>
* Refactor: Remove the old user status (reaction/emoji)
* Update settings.yml
* test: remove old user status testing code related
---------
Co-authored-by: Anton B <antonbsa.bck@gmail.com>
Webcam pagination has a timed camera negotiation debounce
after a page change is triggered. The goal is to avoid overlapping
negotiation requests on sequential page changes. That value is
configurable and set to 2.5 seconds by default, which is too
conservative for today's standards.
Lower the default pageChangeDebounceTime to 1s.
* feat(html5): initial implementation of Gladia transcriptions to BBB 3.0
* fix(transcription): Add missing locales and fix invalid cc menu key
* fix(bbb-transcription-controller): Bump transcription controller to fix some bugs
* fix: adjust yq syntax for setting fs esl password in transctiption-controller
* fix(transcription): Use newer useSettings format from transcription options
* fix(captions): Correctly use captions settings
---------
Co-authored-by: João Victor <joaovictornunes973@gmail.com>
Co-authored-by: Anton Georgiev <anto.georgiev@gmail.com>
Co-authored-by: Ramón Souza <contato@ramonsouza.com>
- 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 [disabled by default] custom heartbeat included in Meteor's server
does not end connections when they are considered unhealthy/stale, which
deviates a bit from the default implementation. See:
https://github.com/bigbluebutton/bigbluebutton/pull/11486.
This commit includes a call to the default heartbeat termination timeout
so sockets are correctly cleaned up when the custom heartbeat is
activated. It also adds a customHeartbeatUseDataFrames config to allow
controlling whether the custom heartbeat should use WS data frames as
valid heartbeats as well - this should only be useful for
testing/debugging purposes and the default behavior (true) is
maintained.
As a side note: this change spun off from an investigation where some
problematic networks were triggering periodic client re-connects due to
the default heartbeat failing. Investigation points to the control
frames being put alongside fragmented WS data frames and the server side
failing to recognize the former - which means pong frames would be missed and
the health check would fail. Since the default heartbeat _does not_
account for data frame traffic (eg DDP payloads), it would shut down the
client's WS even though it was healthy.
The custom heartbeat _does_ account for data frames, which mitigates
that scenario and prevents unecessary reconnections.