It could happen that an old session id expired while a user already re-joined
a room with a new session id. Once the old session id expired, the user got
removed from the room.
Signed-off-by: Joachim Bauch <bauch@struktur.de>
Although the server will refuse to set an empty room name "validate" was
implemented in "Room" model, which prevents "Room.save" from even
sending the empty name to the server.
The EditableTextLabel now checks too if an "invalid" event was triggered
when calling "Model.save", and if that happens it simply hides the input
showing again the label without changes; it would be better to keep the
input and show the error message instead, but for now it is good enough.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Now there is no longer a "New group conversation" item shown in the
conversation list dropdown; instead first the desired conversation name
needs to be typed in the search input and then the group conversation
with that name is selected in the dropdown.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
SimpleWebRTC expects that screen offers from remote peers include the
"broadcaster" property set to the ID of the peer; this is used to set
the "sharemyscreen" property, which is used to differentiate Peer
objects for sent and received screens.
Screen offers received from the MCU do not include the "broadcaster"
property, so SimpleWebRTC mark the Peer objects created from those
offers as local screens. This causes, for example, that the remote
screen peers are ended when the local screen is stopped.
Due to this, now the "broadcaster" property is added to the screen
offers received from the MCU before they are processed by SimpleWebRTC.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
As screen sharing is unidirectional there are separate Peer objects for
the screen sent to and the screen received from a remote Peer. When the
MCU is used there is a single Peer object for the screen sent to (as it
is sent to the MCU), but when there is no MCU there is one Peer object
for each remote peer that the screen is sent to.
In that later case, the Peer objects for the screen sent to and the
screen received from a remote peer have both the same session ID; the
only difference between them is in the "sharemyscreen" property, which
is "true" for the screen sent to the remote peer.
Due to this, when looking for stale peers the Peer object for the local
screen needs to be ignored; otherwise when the screen offer from the
remote peer is received the Peer object for the local screen would be
seen as stale and removed due to having the same ID and type.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the MCU is used and the local screen is shared the screen is not
directly sent to the remote peers, but to the MCU, which then relays it
to the desired remote peers. Thus, when the local screen should be
shared to a remote peer the MCU has to be notified to send the screen
offer to the remote peer. Then, when the remote peer receives the screen
offer, it creates a new Peer object for the received screen.
The MCU was notified to send the screen offer only if there was no
screen Peer object for the remote peer. Due to this, when a remote peer
shared the screen with the local peer and the local peer then shared the
screen with that remote peer no screen offer was sent, because there was
already a screen Peer object for that remote peer.
To fix this, now the screen offer is sent whenever the local screen is
shared with a remote peer. Note that this should not cause duplicate
offers, as the offer will be sent only when the screen sharing starts or
when a new user joins the call.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The explanation below only applies when no MCU is used; the issue
happened both with and without MCU, but the code paths were not modified
when a MCU is used, so the bug is still present in that case.
When the local screen is shared a new screen peer is created for each of
the remote peers. However, when a screen offer is received a new screen
peer is created too; as screen sharing is unidirectional there are
separate Peer objects for the screen sent to and the screen received
from a remote peer. As both Peer objects are for the same remote peer
they have the same session ID; the only difference between them is in
the "sharemyscreen" property, which is "true" for the screen sent to the
remote peer.
Due to all this, when sharing the local screen it is not enough to check
if there is already a screen Peer object with the remote peer id to
prevent creating another one, as that screen Peer object can represent a
screen received from the remote peer; it is necessary to ensure that the
Peer object represents the screen sent to the remote peer using the
"sharemyscreen" property.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
As it is a boolean flag just set once and only needed when the current
user is a guest an implicit attribute added dynamically is now used
instead of an explicit attribute; "_" was prepended to the name too to
mark it as "private".
Note that in the embedded Talk UI there was no explicit attribute, so
the condition would have never passed and the hint would have never been
shown. However, as the embedded Talk UI is currently not used with
guests it was not an issue.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
In the embedded Talk UI the local video container is not hidden, so
there is no need to remove its "hidden" CSS class when the local media
is started.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the audio is set as available it is followed by a call to
"setAudioEnabled(bool)", so the state of the audio button just set was
always immediately overriden. Moreover, as only the button state but not
the related attribute was set the view was left in an inconsistent
state.
It is currently not possible to directly call "setVideoEnabled(bool)"
from "hasVideo()", so for consistency both "hasAudio()" and "hasVideo()"
expect "setXXXEnabled(bool)" to be explicitly called after they are
called.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The audio and video are explicitly set as disabled before they are set
as not available, so there is no need to set them as disabled again.
Moreover, even if they were not explicitly set as disabled it would not
be really necessary to disable the audio and video when they are not
available.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The condition passes when the video is available, but it will only be
executed anyway if the video is available due to the initial condition
in the method.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Joas Schilling
Joas Schilling
Joachim Bauch
Nextcloud bot
Daniel Calviño Sánchez
Peter Edens