- Removed the connection-status history from the user list's gear
icon and now is opened by the connection-status button. Moderators will
render the same modal as before and viewers will only have access to their
own data.
- Added data-savings shortcut at the connection-status modal.
- Added websocket round-trip time.
* updating old tests + collecting more snapshots [WIP]
* updates old test suites and collects more visual regressions screenshots
* remove snapshots and their collection temporary
* run tests from packages.json
* update test execution command/export constants from .env to core/constants.js
* update tests/puppeteer/README.md file
* update LOOP_INTERVAL variable call and assign timeouts to the webcam share spec
* redefine waitForSelector func in page.js, update chat test suite specs and add poll chat message test spec
* Merge remote-tracking branch 'upstream/develop' into updating-old-tests-visual-with-visual-regressions
* update webcam test specs collecting videoPreviewTimeout and use it to wait for videoPreview selector
* update custom parameters test suite
* update breakout test suite
* update webcam layout test suite
* update multiusers test suite
* update notifications test suite
* update presentation test suite
* whiteboard test suite
* screenshare test suite
* update sharednotes test suite
* user ELEMENT_WAIT_TIME variable from timeouts constants.js
* list TEST CONSTANTS by category
* add poll test suite and assigns the right unassigned timeouts
* set test pages to headless
The debounce method argument was being passed wrong (its supposed to be a method, not a function call), thus spewing exceptions in the console and rendering the debounce virtually ineffective
This happens because FreeSWITCH is not able to parse the "From" header when it has multiple occurrences of ':'. So user is not able to join audio.
To fix, we now changed the "callerId" to use the base64 value of the user name, instead of directly using user's input (the callerId format keeps being a triple like this: <user_id>-bbbID-<base64_encoded_name>).
Once this callerIdName is encoded at the same point it is generated, there shouldn't be server side effects for changing this value; except for those places where the callerName is retrieved by splitting this triple (such as the voice talking-indicator, as described below).
Updated the talking-indicator to retrieve the username from User's object, instead of retrieving from the one username generated by splitting the callerId triple.
This problem also happens in versions <= 2.2.26.