It is safer to look at subscriptions's state to users instead of depending
on the initial state of the collection at mounting time. Although
i couldn't force any race conditions on this, there's a chance it could
happen. The fix avoid this problem.
This complements #11533
When validating tokens, the dummyUser created at the beginning is set
with validated=true. This means there won't be the state change that used
to occur from validated:false to validated:true (which detects the moment
joined the meeting) , therefore the alert code that expects for this change
won't run.
To fix this for audio alerts, we now detect when user join by observing
additions in Users's collection. This is actually good because we start
observing this only once (in componentDidMount), differently we used to do,
by calling this every time the tracker was activated.
To distinguish between the user addition that initially populates user's
collection from those that happens after user join (which are the ones we
want), we store the initial state (at componentDidMount) and compare it
with new additions. If the user added is present at the initial state,
then it is an addition to populates the collection, otherwise this is a real
user addition (happened after user joined the meeting)
Partially fixes#11399
When refusing ("thumbs down" button) echo test, user is able to select a different input device. This should work fine for chrome, firefox and safari (once user grants permission when asked by html5client).
For output devices, we depend on setSinkId function, which is enabled by default on current chrome release (2020) but not in Firefox (user needs to enable "setSinkId in about:config page). This implementation is listed as (?) in MDN.
In other words, output device selection should work out of the box for chrome, only.
When selecting an outputDevice, all alert sounds (hangup, screenshare , polling, etc) also goes to the same output device.
This solves #10592
