If a device is currently active and a different one is requested Firefox
returns the currently active device. To overcome this all the tracks of
the same device kind as the requested one are stopped before performing
the request.
However, a device is also "active" as long as any other device returned
in the same "getUserMedia" request is active. Both audio and video are
requested at once when a call is started, so during calls it was needed
to stop both devices first to be able to switch just one of them.
Moreover, since Firefox 88 there is a grace period for requesting again
the media permissions to the user once a track stops. During that grace
period the device is also "active" and it is not possible to switch to
another device even if the previous one was requested on its own,
without any other device. In this case the permissions have to be
manually revoked to be able to switch to another device before the grace
period ended.
To solve all that now the ID of the requested device is marked as a
required constraint instead of an optional one, which forces Firefox to
honour the requested device and return it instead of the active one.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Added fetchConversations tests.
Added maintenance mode and talk hash check in conversation tests.
Added talk hash store tests, also for maintenance mode check.
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
Move fetchMessages and lookForNewMessages to store actions, including
logic for cancelling them.
Removed store usage for these functions in messagesService and moved it
to the store actions.
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
When a call started and the VideoConstrainer was created the video track
was assumed to be already in high quality, so when the VideoConstrainer
was asked to apply again the high quality constraints it just ignored
the request. However, in some cases the browser does not initialize the
camera in high quality, so the camera was kept in a lower quality for
as long as the high quality was kept being requested.
Moreover, even if the browser initialized the camera with high quality
that quality might not be exactly the same as the one set when applying
the high quality constraints, so even in those cases the constraints
should be applied anyway for consistency.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The flag that keep track of whether the quality warning tooltip was
dismissed was a local data of the LocalMediaControls component, so it
was reset when a new instance of the component was created again. As a
new instance could be created several times during the same call (for
example, when switching between speaker and grid mode) the warning
tooltip could appear again after being dismissed. Now the flag is kept
in the store and shared between different instances.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Nextcloud bot
Ivan Sein
Joas Schilling
Joas Schilling
Daniel Calviño Sánchez
Vincent Petry
dependabot[bot]