Before, deleting a room and removing oneself from a room had the same
behaviour: if the room was the active one it was first left and, then,
the room was destroyed. However, while that still happens when deleting
a room, when removing oneself from a room now the room is first
destroyed and, then, the room is left; as destroying the room can be
rejected by the server it is necessary to wait until the room is
destroyed to leave it and update the UI accordingly.
The empty content view expected that a room was always left before being
destroyed, so the change in the order of events caused that when the
room was destroyed the initial message was set, but when it was then
left the initial message was overwritten with the conversation ended
message; now the conversation ended messsage is set only if the room was
not destroyed before it is left, which fixes the wrong behaviour when
removing oneself from a room without affecting the behaviour when rooms
are destroyed or the user is removed by a moderator from a room.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Delete - is only available to logged in moderators and owners
Leave - is always shown, when Delete is not shown, or
when there are other other users and it's not one-to-one
Signed-off-by: Joas Schilling <coding@schilljs.com>
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>
Nextcloud bot
Joas Schilling
Daniel Calviño Sánchez
Joas Schilling
Joachim Bauch
Peter Edens