The chat between two users was tested by a sequence of one user sending
a message and immediately after that the other user sending another
message. Most of the time the messages were processed in the server in
the order in which they were sent, but sometimes it could happen that a
previous message took longer than usual to get to the server and then
the next message from the other user was processed before it; in those
cases the test failed due to the messages not matching the expected
order. Now each user waits for the last message of the other user to be
received before sending the next message.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
No functional changes yet, but this will allow later to use the standalone
signaling backend to notify clients about new chat messages without having
to poll (see #624).
Signed-off-by: Joachim Bauch <bauch@struktur.de>
When the chat view is shown in the main view the call UI (videos and
screens) is hidden using a CSS trick. However, when there is no chat
view in the main view the elements for videos and screens were always
visible. Those elements are initially "empty", but once the user joins a
call they are filled with contents (like the icon to mute the own audio,
or the avatar of the speaking user). As the elements were always visible
the call UI was shown in the main view after a room was left (either
explicitly or implicitly, for example, if the moderator deleted the
room), as in those cases there is no chat view hidding them.
Besides that, the empty content element was hidden when joining a call
but never shown back again. Due to that when a room was left after
joining a call the empty content element was also missing.
Now the videos, screens and empty content are explicitly shown or hidden
as needed when the user joins a call, leaves a call, or leaves a room,
just like it is done with the chat view.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
In order to check if certain conversation is the active conversation
the element for the active conversation list item with the given name
was found and then it was verified that it was visible; waiting for the
element to be visible using the implicit wait made to find the element
is a valid approach if the element is always visible when it exists in
the DOM. However, during the lapse between removing/deleting the
conversation and getting the updated conversation list from the server
the element may be hidden but exist in the DOM. Due to that it has to be
explicitly waited for the element to be visible.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Depending on timings it could happen that the guest name was set before
the room token was known (resulting in `null` in the url) or before the
user has joined the room (so setting the name got rejected).
Signed-off-by: Joachim Bauch <bauch@struktur.de>
This avoids a conflict (introduced by #864) with the existing ´usersChanged`
event which is triggered when the `inCall` status of a user has changed.
Signed-off-by: Joachim Bauch <bauch@struktur.de>
When explicitly leaving the current room through the room list view the
chat view was detached. However, as the internal state of the
Application object (which manages the placement of the chat view) was
not updated the chat view was always hidden from that point on until the
page was reloaded.
Moreover, as the chat view was detached only when explicitly leaving the
current room the chat view was not hidden for other users in the room if
it was deleted by a moderator.
As the "leaveCurrentRoom" event is triggered in the room channel when
the current room is left, either explicitly or implicitly, now the
Application object listens to that event and hides the chat view as
needed when it is received.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
If the same user joins the call again, the video would otherwise not be
promoted automatically because the id is still stored in `latestSpeakerId`.
Signed-off-by: Joachim Bauch <bauch@struktur.de>
Otherwise messages like `refresh-participant-list` could be stored in the
database even if standalone signaling is used.
Signed-off-by: Joachim Bauch <bauch@struktur.de>
When we delayed the media access, we were all fast with testing.
Before this patch, when there was already at least one user in the
call and you took longer to accept the media request than webrtc
took to init everything, you would always send a black video signal
and no sound, because the data was not there, when connections were
established with the other users. Now we first request the media and
send the join call to the server afterwards.
Signed-off-by: Joas Schilling <coding@schilljs.com>
Daniel Calviño Sánchez
Joas Schilling
Ivan Sein
Joachim Bauch
Joas Schilling
Joachim Bauch
Nextcloud bot