Because useMeasure always returns a width and height of zero on the first render, various call UI elements would flash in and out of existence or animate in from the wrong place when joining a call. This poses an accessibility issue, and is generally unpleasant.
We didn't check whether we actually had a video device when seeing
if the current video devices was in the list of devices, so this
caused loops which confused Safari.
Because connecting tiles don't have a feed, clicking the local volume button would cause a soft crash. This also fixes a few strict mode errors in the surrounding area while we're at it.
The 'connecting' tile change meant that we could have tiles right
at the start of the call where we wouldn't have before, and in fact
could have tiles for other users before we even had a tile for ourself.
This threw off the logic for ordering tiles which had a special case
for 1:1 calling which assumed that one of the tiles in a 1:1 call was
the local user. In this case, this assumption wasn't true at the very
start of the call, so the tile orders got assigned incorrectly and then
persisted for the rest of the call.
Fixes https://github.com/vector-im/element-call/issues/694
React 18's strict mode intentionally mounts all components twice, which was causing Olm to get double-loaded. Also, it doesn't need to be loaded if the app is running as a widget.
It's normal for the play operation on video feeds to be cancelled due to tiles unmounting quickly (especially with React 18's strict mode), but it logs a scary error which can be misleading during debugging.
RoomWidgetClient doesn't do lazy loading, so it only has the state event data to work with and not the lazy loaded user object.
Previously avatars of remote participants were all replaced by fallback avatars.
The join handler was requesting a stream with both video and audio, even if the system lacked video or audio devices. Requesting one of audio or video is enough to get all device labels.
* Make the embedded mode screen sharing a request-each-way rather
than request-and-reply, since replies time out and so can't wait
for the user.
* Try normal screen sharing first, then fall back to using the widget
API if it fails (for lack of a good way of detecting when we
should be using the widget API).
Fixes https://github.com/vector-im/element-call/issues/649
