* bad set state (actionsBarContainer)
* bad set state (appContainer)
* isMobile should be ismobile warning
* bad setState (notes)
* bad setState (user-notes)
* bad setState (user-participants-title)
* bad setState (webCamContainer)
* bad setState (PresentationMenuContainer)
* fix webCams not working issue
* fix userList user counter not working issue
* fix TS lint
* fix TS lint
* fix TS lint
* Later changes
* fix first wheel zoom always going to top left corner
* focus button zoom on center of page after wheel zoom
* test: update zoom test to avoid snapshot miscomparisons when zooming in and out
* test: fix usage of hasText function params
---------
Co-authored-by: Anton B <antonbsa.bck@gmail.com>
* 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>
* feat(layout): add propagation toggle
Transforms the 'update everyone' button in the layout modal into a
toggle, so that presenter get immediate visual feedback of the current
layout propagation setting when the modal is opened.
* fix: update propagation button locale to 'update to everyone'
* test: update layout test
---------
Co-authored-by: Anton B <antonbsa.bck@gmail.com>
Adjust an inline comment in connection status' service about packet loss metric
usage.
Now it correctly states that the absolute counter SHOULD NOT be used for
alert triggers.
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
